Sweet, Glitzy Traps


Given yesterday’s news on Adobe ceasing development of their Flash player for mobile devices (read: Adobe killing Flash) I can’t help but recalling the post I’ve written back in 2007 on my old blog – it was titled "Why I don’t get Adobe Flex" and generated a heated discussion in the comments section back then.

Vendor lockdown. You know it when you see it. Sometimes the market forces are so strong that you basically have no choice but to walk into the trap eyes wide open. However, I’d argue that this was not the case with Flex, Flash and HTML. In many cases, the choice of Flex (or Silverlight for that matter) was a silly choice made by unqualified and uniformed decision makers (CEOs, CTOs and developers..) blinded by Adobe’s and Microsoft’s brochures and evangelists.

Our industry is maturing rapidly though. It seems as if even the vendors realized that vendor lockdown in the form of proprietary technology is evil and are actively refraining from creating such traps.

Where would you say is the next trap we’ll regret walking into 5 years from now?

My bet is on the various cloud platforms and these wonderful little time saving extra services they provide.

Here is a repost of that old post:

Why I don’t get Adobe Flex, originally published Feb 22, 2007

I don’t get Adobe Flex.

Actually, Flex looks great. Solid architecture, slick IDE, modern declarative markup language and scripting language, lots of productivity features.

Still, I don’t get it. Why would an architect choose to rely on a proprietary runtime, available only from a single vendor to do stuff that can be done just as easily with standard XHTML, CSS and JavaScript?

I chatted on Flex with Mark Anders from Adobe. Mark worked on ASP.NET from 1998 until 2003, and then co-founded the Flex effort at Macromedia.

Mark demoed Flex at FOWA today, building a functional, slick Flickr tag browser in few minutes using the Flex markup and practically zero code. The thing is that the exact same day can be built with just as easily with an environment like ASP.NET, with the output delivered to the client using standard XHTML CSS and JavaScript. So why Flex?
Is Flex Adobe’s way of leveraging the huge Flash developers community and lure them into a vendor-lockdown?

According to Mark, Flex is a way to avoid the browser compatibility issues, especially with regards to CSS and JavaScript. It’s a reliable, predictable runtime that works the same way on all browsers.

Flex must have been a huge engineering effort. Could the same effort have been dedicated to delivering the same productivity and reliability advancements, but with the markup and the script "compiled" into XHTML + CSS + JavaScript instead of proprietary Flash runtime bytecodes?

And what about search engines and other content-aware tools, which cannot easily access the content delivered by Flex applications? And permalinks, which do not work as naturally with Flex as they do with HTML? How do you bookmark a piece of content in a Flex application on Delicious? And – which surprises will you run into when you hit the browser’s Back button?

The upcoming Apollo server platform from Adobe promises to deliver support for rich web applications that work equally well offline and online. This is something I’ve been looking forward to for a long time. Of course, it will require the Flex runtime to provide this functionality. Technically speaking, I don’t see a reason why the same capability cannot be delivered through standard XHTML + CSS + JavaScript + a client-side plugin, which could be a subset of the Flex-required Flash runtime.

Given Adobe’s track record with Flash and its 98% penetration, I think it’s safe to guess that Flex will be hugely successful. Still, I can’t help but feel that in a sense, it’s a step backward. Or at least sideways.

Technorati Tags: Adobe Flex Mark Anders Flex Standards