Michael Koch has a timely and well-written article in the June issue of Adobe Edge magazine titled Flex 2: What's in it for Flash Developers?

I was very positively surprised when Michael first contacted me regarding the article to learn that Adobe had commissioned a piece on Flex targeted at Flash Developers. You see, traditionally, Macromedia's approach was to try and differentiate the two products as much as possible, even if this meant condoning -- if not actively perpetuating -- certain myths about Flex.

One can only theorize whether there was any correlation between this approach, the large price difference between the products and the apparent profit to be had from the sale of server licenses. All in all, I have always questioned the extent of honesty and transparency that would be inherent in such a strategy, were it ever official policy, and have publicly written and spoken regarding it many times, as have others.

Flex Myths from a Bygone Era

The top two myths about Flex-the-elder were the following:

Myth: You need to run Flex as a server

Truth: You could always create SWF files using the Flex compiler and deploy them without the Flex server. You would still need to purchase a server license for each computer you deployed Flex SWF files to.

Reason: The only reason I can fathom for perpetuating such a myth would be to increase the number of server licenses sold. Flex is a great compiler but a lousy server. By lousy, I mean that it doesn't handle load well at all. It does, however, scale well through clustering. And we all know that the more you cluster, the more server licenses you have to buy.

Developers unfortunate enough to buy into this myth -- mostly Java houses because it validated their belief in the superiority of all-things-Java by mirroring their existing workflow with JSP -- probably ended up paying for lots of server licenses that would not have been necessary if they had deployed plain SWF files to the server. It is not inconceivable, thus, that many Java houses ended up paying quite handsomely for their vanity. Alas, vanity is usually a trait that comes with a high price tag, as opposed to the bargain-basement discounts that may be had through a sound investment in pragmatism.

Myth: Flex and Flash are very different beasts. Flex is for programmers, enterprise developers, software engineers and Flash is for "pixel pushers".

As famously quoted in the Macromedia Press book on Flex, Macromedia was trying to carve a very limited niche for Flash Developers as people who create skins and perhaps components for the big boys to use in their "enterprise applications". I experienced this first hand when my article for Macromedia Edge on "Migrating a Flash Application to Flex" was retitled without consultation at the last moment to "Tips for Using Flash Assets in Flex Applications". (You can find an expanded, unedited version of my article here.) At the time, in line with its "enterprise" positioning of Flex, Macromedia did not want you to know that it was actually trivial to port a well-architected Flash application to Flex as it revealed how similar the two products were.

This new placement of the role of the Flash Developer at once displayed a lack of understanding of the complexities involved in UI and component design and development as well as an unexplainable amnesia with regards to the amazing applications work performed by Flash developers in the past. It also reflected well the arrogance of certain Java developers, who, possessing ultimate knowledge of The One True Way, were merely enlightening the primitive Flash natives with the wisdom of their gospel. In due time, the natives found that they had to teach the Enlightened Ones what a movie clip was, but that's another story!

Truth: Flash and Flex are very similar indeed. Flex, at its core, is nothing more than a framework, written in ActionScript 3 (and previously, in ActionScript 2), that runs on the Flash Player. In compiling Flex applications, MXML is translated into ActionScript and that resulting ActionScript is compiled into SWF bytecode. Thus, for all intents and purposes, the Flex framework could have been written using the ActionScript editor in the Flash IDE! There is, of course, more to Flex than just the framework. There are the compilers, which compile MXML and ActionScript 3, a visual development tool, Flex Builder, and a server, Flex Data Services. Although, technically, there is little to differentiate the two, in terms of workflow, efficiency and use cases, there truly is a world of difference.

The primary advantage of using the Flex framework with Flash Builder over the Flash framework with the Flash IDE is the ability to declaratively create user interfaces. This tag-based, hierarchical, XML-based approach provides a number of key workflow and productivity enhancements over the layout of user interfaces in the Flash IDE. The first such advantage is that MXML files are text based as opposed to the binary FLA file format. This makes them easier to version control and, more importantly, to diff. The importance of this in team environments cannot be overstated. Secondly, the hierarchical structure of XML fits perfectly with the hierarchical structure of user interfaces and the component model in MXML provides a neatly encapsulated modular framework with an elegance that eludes other similar languages such as Microsoft's XAML and Laszlo's LZX. The Eclipse-based Flex Builder 2 tool itself also offers a huge productivity boost.

That is not to say that Flex is The Ultimate Answer To All Things Flash. The size of the framework itself is a major hindrance to the use of Flex in consumer-facing applications. The smallest Flex application weighs in at around 150kb due to the size of the Flex framework. Although is acceptable for intranet and business applications, it is not something you would use to create your blog. (300-400kb would probably be the minimum size of a real-world Flex application with branding, etc. and a considerable amount of code.)

Reason: Macromedia wanted to differentiate the two products as much as possible to justify the difference in price point between the two.

Flash Forward: Flex 2

I am very happy to see how Adobe is currently positioning Flex 2 and I'm impressed by the transparency with which they are approaching things. Their new approach with Flex 2 is a healthy, long-term one. I've said, more times than I can remember, that we need more developers on the Flash Platform and Flex 2 is just the framework and toolset to entice these people.

In looking for new developers for Flex, however, we should not ignore the fact that we have a large pool of Flash Developers who already know much about Flex (through their ActionScript and Flash knowledge) but perhaps are either not aware that they know as much as they do or have been frightened by the myths surrounding Flex in the past. It is imperative that we support Flash Developers who want to learn Flex and break down the misconception that Flex is a complicated tool that can only be understood by a handful of superhuman software engineers. Michael Koch's article is a great step in this direction and I am glad to see Adobe doing the right thing with Flex 2.

Personally, I'm having more fun I've ever had in developing Flash applications since I started using ActionScript 3 and Flex 2.

For more on Flex and Flash, read Michael's article on Adobe Edge. You can read more of my thoughts starting on the third page of that article.

The Flex 2: What’s in it for Flash Developers? article by Aral Balkan, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Noncommercial 2.0 UK: England License.