Picking technologies on the right side of history
swombat.com
swombat.com
After all, if you don't provide the good user experience in 2007 (when it might not have been possible to do so in JS) then you won't be around in 2011 to complain about technology having moved on.
Heck, it might require less effort overall to write it once in Flex, and then rewrite it in JS four years later than it would have done to write it in JS in 2007 and then keep it up to date with a changing JS landscape over that time.
And you can't ever be sure that you picked the technology on the right side. So design your systems so that it doesn't matter which side wins, you can adjust to the new reality and keep going.
That's definitely one way to do it, but it depends on the technology and the resource constraints. Ultimately, you have to pick some technologies to rely on. Sure, in theory you can architect your multi-tier app so that you can swap out Java for .NET, or Python for Rails, or Postgres for MySQL, or even HTML/JS for Flex, but those are all difficult and costly swaps to perform. And most startups can't afford to build expensive components twice. They have to make a gamble.
Full-Flex front-end was an accepted model in 2007, with a fair few apps following it. Yes, we could have built just the explorer component in Flex, but that would have had a number of other problems (such as loading times every time you changed a tab, for example). More critically, when we started we had only a vague idea of what this explorer tab might look like. Like many startups, we were discovering our customers' actual needs as we went along, and so it wasn't possible to just declare "the explorer component will look like this and it will be built in Flex", because to be honest, though we suspected the explorer component would be important, and had some ideas about what it should look like, those were completely unchecked assumptions.
And you can't ever be sure that you picked the technology on the right side. So design your systems so that it doesn't matter which side wins, you can adjust to the new reality and keep going.
You can't ever be sure that you did pick the right technology to "stand the test of time", but sometimes you can be relatively sure that you didn't. Even in 2007, for anyone with good knowledge of Open Source, it was clear that eventually, Flex would be losing to open technologies. It wasn't clear how long that would take, and whether Adobe might counter that by opening up Flex, but certainly there were strong concerns about Flex (which we were aware of, but didn't really factor in as strongly as we should have). Similarly, anyone building a startup that critically relies on Java (or, more controversially, PHP) today is picking a technology that's waning and will certainly be largely irrelevant in 1, 3-5 (most likely), or 7 years at most.
Especially if it was indeed as clear at the time that Flex was doomed as the author claims. Hindsight is 20/20 - "the history test" is BS without the benefit of it.
I had very similar intuitively negative feelings about ExtJS last year. It's not one of those things you can just swap out, you have to write the web application in a particular way to support it.
If I was back in 2007 and had to build a rich GUI interface that would work with IE6 as well as modern browsers I can't really think of any other option but to either use flash/flex or severely restrict your expectations. As it is now there is still a fair few things that cannot be done well (webcams etc) with standard HTML/JS (especially if you are not running a super uptodate browser).
The problem with these technologies is that feasibility is really in the hands of a minority of big corporations (MSFT/Apple etc) who are the gatekeepers and make decisions about the platform, they problem is that they often work in secret.
Let's face it , the biggest reason behind the "death of flash" is that apple announced they would not support it on their newer tablet and phone devices. If this hadn't happened plenty of people would still be merrily writing flex code for the web.
The problem with the secrecy that these corporations work on their products with is that developers literally have no idea what will happen, if Apple had made a friendly warning to web devs saying "hey, trust us you should really stop using flash if you want to work with our devices" a year before they ipad came out there would be less people having problems.
Let's say hypothetically that Microsoft suddenly came out next year and announced that (for example) they were going to trash all support for .NET across all platforms for windows 8 onwards (including server) and had decided that everything should be written in python if it wanted to run on their OS, no exceptions.
Obviously lots of python devs would rejoice with the headstart they had, but firms that had invested significant time and money intro creating large apps with big codebases in .NET etc would be completely screwed. Obviously Microsoft generally don't pull shit like that (quite as much) but Apple would be more likely to do that kind of massive change and they are gaining market share..
My feeling (and I've spent some time thinking about this since we're going through the same thought-process right now for a project) is that the write it in 2007 in Flex and translate it now to JS is actually the cheaper option. The frameworks for large JS projects that we have now just didn't exist in 2007.
This is without including things like comparing the present value vs. future value of money or the risk that the fancy Javascript code you are spending tons of time building (which was much faster to build in Flex in 2007) is going to be useless since no-one actually wants what you are building.
If you pick something like Markdown (for basic structured text), JSON (for data structures), or XML (for more complex document-based data), and structure your data first you're going to be better off than jumping into a front end design and working out the back end along the way.
I agree with AndrewDucker to a certain extent: structuring your application architecture to allow one to move from one sub-system to another is ideal. While appropriate in generalities, it's the specifics that matter. Most substantive environments don't interact with these systems through a simple connection that can be hot-swapped. There are dependent processes that are often designed around the fundamentals, quirks and intricacies of a given technology.
The scope of one's implementation definitely affects how much you can hedge your bets if you need to shift to another technology stack.
But there are a lot of indications they are moving away from it in all places they can. They still use it for front end work, but even there they have been one of the biggest innovators coming out with the HipHop PHP compiler.
Behind that they also came up with the Thrift RPC framework specifically so that the rest of their code and logic could be written in many other languages including Java, Python and Erlang.
Facebook is a lot more than PHP and they've pushed PHP innovation a lot too. I find their use of PHP as no clear indication PHP is the right or wrong choice. It's just the choice they made 7 years ago and are living with
If the author of this article had the dependencies and resources of Facebook, building their own Flex-based environment independent of Adobe is an option they may have considered as well.
In this case, it was more cost effective to just rewrite the application in another language. Facebook found it cheaper to rewrite the environment. But the end result of breaking ties with a third party appears to be the same.
All of this applies to PHP, so I can't see it being killed off anytime soon, regardless of technical merit. (I wouldn't choose it for a bunch of other reasons, but those are subjective)
(not trying to bash Perl, but it's hardly the most relevant language to web development today)
What on earth does that /mean/? What would make a language relevant? Would it be a huge community writing and releasing code every day? (http://search.cpan.org/recent) Would it be lots of conferences? (http://lanyrd.com/topics/perl/past/) Would it be sexy startups using it? (http://duckduckgo.com/, http://selectablemedia.com/)
So...?
PHP has been and will be on the wrong side for the very long time ahead.
When you write your data model in a language that works on client and server platforms, you save lots of duplication of effort and gain flexibility. The best example of experiencing the opposite I have is a fairly large application I worked on, where the backend developers designed a totally different set of classes around a (pretty much undocumented) XML structure than the frontend guys. Basically all communication happened through XML. Sure "it's an open format!", "it's human readable! (in a sense)", but taking over this project figuring out semantics and what was considered valid became a painful effort.
Your frontend should always use the same domain model as the backend. Designing the fundamental parts of your application without relying on an ORM, XPath, JSON, .NET, Scala case classes, Flash, Javascript, HTML5, Swing, whatever... makes you platform agnostic and shrug at the next internet technology death.
Am I happy Flash is considered dead? No, currently HTML5 lacks many features I rely on today and sanity (isn't it kind of bizar we consider cross-browser issues as normal?). Will my skills and all of my codebase die with it? Absolutely not.