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.
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.