A Summary of RIA Development Tools*: Past, Present and Future

I remember the first time I ever saw a Toys R Us. I was living in Malaysia at the time and we had gone on a holiday to Singapore. As I was already a geek at the tender age of nine (having fallen in love with that huge metal box that was my first IBM XT at age seven) I was more interested in the computer stores than anything else. My goodness, they had the latest stuff: I remember seeing my first EGA card... 16 colors? Really? Amazing! But nothing had prepared me for my first sight of a Toys R Us. For a semi-spoiled-nine-year-old only child, the sight of the four-story behemoth filled with nothing but toys was a spritual experience (my parents would probably counter that it was quite a material one for them!) Shelves upon shelves of possibilities...

So what has this to do with RIAs?

Just yesterday, it seems, if you wanted to build a rich-client web application you had a very limited number of choices: Either use the Flash IDE or go with a Java-applet solution ("solution" in this context is used synonymously with "problem".) Oh yes, and let's not forget AJAX -- the latest hack in the attempt to use a non-state-maintaining system designed for document display for web applications (the first big one, of course, was sessions.) Although humbled by the ingenuity of the HTML crowd at building workarounds that put The Incredible Machine to shame (and coin snazzy acronyms to market them), it's really more than a little short-sighted an approach when it is clear that you need a state-maintaining client to effectively and efficiently build usable RIAs that can be easily maintained and scaled. This has always been Flash's strength. It's biggest weakness, until today, was the lack of a suitable IDE. Today, however, it seems like everyone and their cousin's closet cleaner is coming up with a solution to make the development of Flash-based RIAs easier and I am beginning to feel like that little kid faced with the possibilities of a huge store full of toys.

First, and foremost, there is Macromedia Flex.

Let's not even talk about the price tag as everything that can be said on the matter has probably already been said on one of the related forums or mailing lists. Suffice to say, the pricing either makes economic sense for your company (in which case it will more than likely be seen as a bargain) or it doesn't. In other words, the price of Flex is irrelevant. What is important is the productivity boost that an RIA team can achieve using Flex and what that means in terms of return on investment.

Fear of the unknown

In my Best Practices Flash & Flex Development course, I take students through the process of porting a well-architected application built with our open-source, pattern-based ActionScript 2 framework (ARP) to Flex. The usual response is one of surprise at how easy the process can be. Since ARP cleanly separates the business and presentation logic in Flash applications and uses the FLA for the sole purpose of laying out forms (much as MXML should be used in Flex), porting an ARP-based application from Flash to Flex simply involves re-creating the layout of your forms in MXML (and quite possibly changing a bit of your View logic depending on whether or not you used Flex-only containers/components in the Flex version of your application.) I usually get an equal amount of surprise from Flash developers who previously thought that Flex was this incredibly difficult and different beast that only seasoned Java or .Net developers could grasp. It's not. If you know Object-Oriented ActionScript 2 you'll be fine with a crash course in declarative UI development with MXML.

For Flash developers who are serious about application development, now is the time to start playing with Flex (well, ok, it was yesterday but we can't do much about that now, can we?) If you haven't programmed in ActionScript 2, what are you waiting for? It's not a very big leap from ActionScript 1 if you were already programming in an Object-Oriented manner and, even if not, it takes my students only two days to get up to speed in the Foundations of Object-Oriented ActionScript 2 class I teach.

Flex and ActionScript 2 are here today and will no doubt be sticking around for a while. They are definitely the direction that things are moving in so I would advise you to get on the train while it's still pulling out of the station.

The toy store

If Flex was the only available technology for creating RIAs, it wouldn't be much of a toy store, would it? Although Flex is my #1 choice, it is nice to see what else is out there or around the corner.

Interesting goings on in Laszloland

Perhaps the most-well-known of the non-Macromedia solutions is Laszlo. Like Flex, Laszlo is a presentation server and was in fact around prior to Flex. With the introduction of Flex, Laszlo Systems chose to open-source Laszlo and it is now available for free download from OpenLaszlo.org.

Similar to Flex, you create user interfaces declaratively using LZX markup. Unlike Flex, which requires the Flash 7 player, Laszlo supports the Flash 5 player (and recently has nominal support for Flash 6 and Flash 7 features.)

If you remember the Flash 5 days, we had an application called Generator. I remember using Generator as part of the K12 Online School, where it would be run in offline mode for a whole day to create the SWF course content for our Flash 5-based virtual school. Generator became somewhat redundant when the ability to load external assets was added to the Flash 6 player and support for it was subsequently dropped.

It is understandable that Laszlo was conceived as an application server, since, until very recently, it only output Flash 5 bytecode and thus needed the sort of server-side processing that Generator used to provide. (In fact, Laszlo uses JGenerator, an open-source Generator alternative.) Of course, since Flex outputs Flash 7 SWFs, there's really no need for it to be a server product and one can only hope that there will eventually be a client-side version available that outputs SWFs directly. In fact, this is exactly the feature that Laszlo Systems has provided with the 3.02b release of Laszlo. It was this feature that made me download and re-evaluate Lazslo. I was impressed with what I saw.

Laszlo 3.02b comes with a component set which would make a Flash developer envious (and yes, I am talking about the super-cool focus management with visual feedback, guys – great work.) There is no doubt that this is a stable, mature platform and the well-written tome of documentation that it comes with makes it a joy to learn and experiment with. It also has a visual builder in the form of the Laszlo Eclipse IDE, built by IBM. (I couldn't get the preview function in the IDE to work with 3.02b.) As I mentioned earlier, the latest version can now also output standalone SWFs that do not require an installation of the Laszlo presentation server in order to run.

That said, even though I may drool at the components and the standalone SWF generation, I cannot see us using Laszlo for our current RIA projects. Its limitations mostly stem from its reliance on the LZX markup language which, although similar to HTML, is Yet Another Markup Language (YAML) to learn. To make matters worse, there's no separating scripting language: You write your classes and methods using tags and – at least in the samples provided – this leads to a horrible mess of presentation and business logic much along the lines of what you see in badly-architected HTML-based web applications with their mix of server-side markup, JavaScript and HTML layout code all in one place. (Can you say "maintenance nightmare?")

I am sure that there are ways to better architect Laszlo applications than what is shown in the sample applications (after all, the Flex sample applications do not demonstrate the wonderful separation of business/presentation logic that is possible with Flex) but, given limited time and pressing deadlines, investing time to learn YAML with a single application domain seems like a waste of time. I would not like to have the task of transitioning a traditional Flash development team to Laszlo whereas I can easily transition them to Flex. In other words, Laszlo doesn't provide an avenue for knowledge reuse for Flash developers. It's a whole new world, a dazzling place I never knew

I am very interested in seeing where Laszlo will be heading next. I do hope that they implement the ability to load in regular SWFs at runtime as this will allow others to extend Laszlo's capabilities at runtime and might make Laszlo more flexible in implement new player features (as mentioned earlier, Laszlo provides limited support for the Flash 6/Flash 7 feature set.)

Do I sniff a NeoSwiff?

As you may have heard, NeoSwiff has gone into public beta. What is it? It is a C# to SWF compiler. Instead of creating your SWFs using the Flash IDE and ActionScript (or MXML and ActionScript), you write all your code in C# and NeoSwiff compiles it to an SWF.

I've been looking at NeoSwiff for a while now and, as Ted points out in his blog post, it is very impressive. However, its main feature, the ability to create SWFs purely through code using C#, may also end up being its Achilles' heel. I, for one, am so spoiled by the ease of declarative UI development in Flex and visual form design (Flex Builder, Flash IDE, etc.) that I couldn't even consider writing code manually to layout my application forms. NeoSwiff may well end-up addressing this issue by implementing code-behind functionality via a visual form designer at some point.

When used with Visual Studio .Net 2003, you get Intellisense, which is notably missing in the current standalone IDE.

Although it doesn't allow for declarative UI development and its current component library is lacking (and doesn't appear to implement standard keyboard navigation/focus control), NeoSwiff does several technological advantages over Laszlo: It outputs Flash 7 SWFs, uses the widely known and supported C# language and allows for the runtime import of external SWFs (so you can use Flash, or even standalone Laszlo SWFs in your NeoSwiff applications.)

NeoSwiff is definitely one to watch. As with all the solutions, I am very interested in seeing how robust their component framework will be and the ease with which I will be able to visually layout my forms.

A XAML future for us all?

Flex, Flash, Laszlo, NeoSwiff

the toy store is filling up, but there's one technology that has the potential to eclipse them all. I'm talking about Xamlon Pro Flash Edition.

Like Flex and Laszlo, Xamlon allows developers to declaratively create their UIs and like Flex and Laszlo, it uses its own XML markup language to do so.

Xamlon's first major distinction is that the markup language it uses, XAML, is one that will be supported by Microsoft in the next generation of Windows, codenamed Longhorn. (Remember knowledge-reuse?)

Another big difference between Xamlon, and say, NeoSwiff, is that while NeoSwiff works with C# alone, Xamlon will support C# and VB.Net. If Xamlon can live up to its promise, its support of VB.Net, if nothing else, will turn the RIA world on its head. Can you image the hoards of VB programmers out there being given the ability to create Flash-based RIAs without having to learn ActionScript?

Finally, Xamlon is not a presentation server: It creates standard, "deploy anywhere and everywhere" SWFs.

Xamlon Pro Flash Edition PR1 has just been publicly released and it is currently not feature complete. The current state of the components (and, again, the all-important keyboard and focus control) is nothing to write home about and the current set of sample applications display XAML in the worst possible light. The XAML in the sample applications is mainly used in an SVG-like manner, creating a mess of coordinates and color values used in drawing paths and fills. In other words, low-level graphical data that should be never be hand-generated and isn't humanly legible even if it is XML. This is probably due to the relative immaturity of the component framework and the lack of standard container components. Hopefully, Xamlon will concentrate its efforts on making the XAML in its future examples resemble the neat and simple MXML of Flex applications.

Regardless of its current state, Xamlon does hold a great deal of promise for the future. One can't fault the technological decisions that the team has made and if they can pull off the actual implementation, you might be hearing a lot more of Xamlon in the coming weeks and months. (One reason why I'm excited about Xamlon is because long-term Flash community veteran Robin Debreuil is actively involved in the project. In fact it is based on his C# compiler that you may have heard of earlier.)

Components, components, components, components, components

Riddle me this, batman? Why is Flex so superior to Flash? Is it because it is a presentation server while Flash is not? No. Is it because it uses MXML and declarative UI development instead of a proprietary, binary format for form layout? (Perhaps, but that's not the real reason.) The Flex Builder IDE? (Undeniably a productivity boost.) The primary reason, however, are the greatly superior Flex components.

The increased productivity teams gains from Flex can be attributed to several factors, the least of which being that it is a presentation server. That fact, as already stated, is irrelevant. Flex could just as easily be a client-side product without resulting in any loss of developer productivity. However, take away the layout containers and you've just lost most of the Flex advantage. Remove the improved components in the Flex component framework and watch the productivity of your teams drop as they reroute application logic development time to implement drag-and-drop functionality. Needless to say, the Flex components and the hugely superior live preview functionality in Flex Builder are the primary productivity factors that differentiate Flex from Flash.

This being the case, the emerging solutions would do well to concentrate their efforts in making their component sets as robust and usable as possible. At the end of the day, I may like programming in C# more than I do in ActionScript 2 (in practice, the two are very similar and I like both of them) but I wouldn't touch a different RIA platform until its components matched or exceeded the usability of the ones provided in Flex. Looking at the current third-party offerings, I see technology choices that excite me but the currently available implementations leave a lot to be desired.

Flex today, Flex tomorrow...

If you are looking to develop RIAs today and in the present, you can't do better than Macromedia Flex. In terms of features, ease-of-development and robustness, nothing currently comes close. My second choice, currently, would be Flash combined with ActionScript 2. Laszlo comes third as it is the only other feature-complete option that exists. However, I have my eye on NeoSwiff and Xamlon and will be following their evolution closely, as should you.

To end, let me reiterate a point I made earlier: If you're a Flash developer who is serious about RIA development, you need to learn OOP (and, although it is not "superior" or anything silly like that, you will have to learn class-based OOP because that's the direction this is all heading in, regardless of whether you end up programming in ActionScript 2, C# or Java) and you need to get started with declarative UI development. There's no better way to do that today than to download a developer version of Flex and get cracking with ActionScript 2 and MXML using the sample applications. Unlike the dead-end of learning a completely unrelated markup/programming language like LZX, you can easily apply your ActionScript 2 knowledge to C# and your MXML knowledge to XAML in the future if you need to.

At the end of the day, the more toys, umm, tools, we have that support, extend and otherwise add value to the Flash platform, the better it will be for us all!

_________________ * Note: The title doesn't say "RIA Development Platforms" for a reason. The Flash virtual machine (Flash Player), without question, is the platform for RIAs. The various development solutions stated here (except for the AJAX hack and the hugely problematic Java/Swing/applet based solutions) all use the Flash platform.