Surely the right thing to do is to write your systems in such a way that you can pull out (say) a file-system explorer written in flex and replace it with one written in JS in as easy a manner as possible.
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.
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.
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.
I think this is missing the architectural problem with Flex- it was more than just Flash widgets. If it were just Flash widgets- that would be fine, and you could swap them out. The problem with Flex is that it takes over much more of the application, handling communication with the server. I always felt that Macromedia/Adobe were trying to just a little bit too much for you to create vendor lock-in.
You really think there's even a chance that java will be 'largely irrelevant' in 1 year? Maybe you should try assessing your prognostication skills by writing down your predictions for 1, 5, 10 years out and see how close you were. I have a feeling you're just as liable to make mistakes trying to guess what will happen in 3-7 years as you are using the best tools at hand today. Whatever you think of java, for example, google 'java is dead' and see how well people have predicted the future. It's still going strong in the enterprise, and even a lot of startups probably do some java in the form of Android apps. Flex has some great things going for it. It's only easy now in hindsight to say that four years ago you took the wrong path.
> Surely the right thing to do is to write your systems in such a way that you can pull out (say) a file-system explorer written in flex and replace it with one written in JS in as easy a manner as possible.
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 a hard time convincing people not to use Flex in 2007 based on my intuitive sense that it was "wrong". It imposes an event model on programming that is "against" the way the web works, so the abstraction tends to be leaky. Someone that understands how the web works tends not to like it, while you could see web novices appreciating how it simplified the programming model for certain kinds of data linked controls.
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.
Completely agree about ExtJS. It is quite valuable in that once you learn it there are a lot of things you can easily throw together that would have been a lot more difficult with something else, but the learning curve is so high that its tough getting new developers to the point where they can add to the code base.
But you also have to ask the following question: Would it have been more expensive to write it in Javascript in 2007 (with the same or close-to-the-same user experience) than to write it in Flex in 2007 and rewrite it in Javascript now.
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.
I'm not sure I'm quite on the "flash is dead" bandwagon just yet much as I would love to see it replaced with something more standard. I agree that it will decline but it's death will be a slow and agonizing one.
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..
End user technologies are less important than API's, which are less important than actual data and the formats used to store it on disk.
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.
This is a rock and hard-place for nearly anyone in this position, as I've been there as well. Most recently, I've seen colleagues have to make choices around NoSql key-value stores (Mongo, Redis, Cassandra, Riak, etc.)
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.
Purely server-side tech is less sensitive to this kind of swing because you control the execution environment. Likewise for open-source software, and software based on open, widely used technologies, protocols and specifications - for example, it's unlikely that HTTP is going away in the time it takes for a startup to outgrow its "startup" status.
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)
That's not really saying anything. Facebook picked PHP in 2004 and is now stuck with it. They have a huge code base in it.
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
I'm not sure that is a good example. I have no insider knowledge of Facebook so I may not be correct, but as I understand it, they switched to using their own interpreter and translate the code to C++ for production. The only remaining ties being the syntax and at least some of the API.
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.
PHP was on the right side of history in history, in the 1990s when it was a new product. Today? It has a lot of competition and is dropping in popularity, although it is still good enough for many purposes. PHP is open source so it will be around for a while.
Agreed. 10 years ago, PHP (like Java) was a great bet, despite its flaws. A startup building a fresh technology stack and picking PHP today is standing on the wrong side of history, though. PHP can't be abandoned in the same way that Flex can, but it can become irrelevant in the way that Perl has done.
(not trying to bash Perl, but it's hardly the most relevant language to web development today)
Possibly he means percentage of new projects using it, or maybe something like its influence on the future, which is related. It's hard to define, but you sort of know it when you see it.
Ever since I've started programming in haXe, it became clear that the language you code in should never be completely tied to a single platform. This article hints at Flex dying and tech needing replacement, yet many parts of an application (lets call it domain model and business logic) should be unique and not rely on a specific platform or data exchange format.
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.
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.