Aral Balkan

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

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

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!

Comments

• Thanks for the very informative evaluation/investigation of the RIA market. I am myself very interested and happy about the way things are going.
  
  Currently the price tag on Flex makes me focus on RIA development with Flash only for the projects I am doing. And I still program all my layout which is very time consuming. I use my own MVC model for my applications, but hope to use some drag-n-drop tool (not Flash) for layout in the future.
  
  

  by Kim Hansen on 2005-04-07 16:02:56

• Hi Aral,
  
  Good points and great Article.
  
  As you mention in your article, the Flex class library makes the difference between Flex and the rest.
  
  Another point I love about Flex is the integration tier facilities where Flex makes easy than Laszlo to transfer data between client and server.
  
  
  
  

  by Carlos Rovira on 2005-04-07 16:49:35

• You put up a mighty big Straw Man there when you discounted HTML-based internet applications in a few sentences.
  
  First is your emphasis on HTML being initially designed to display documents. Last I checked, the Flash Player was initially designed to play vector-based animations -- hardly a solid foundation for an application platform.
  
  Second, is your assertion that DHTML page cannot maintain state. Certainly you know this to be untrue. And while for a long time I considered that to be one of the SWF's advantages, I'm now completely unsold on the idea that this is advantageous for a web-based solution.
  
  Maintaining state on the client can't be a goal of an app. The advantage of doing so in Flash was that work could be done on the client to prevent round trips to a server that necessitated page refreshes. The DHTML world has figured out how to do that as well, with things like asynchronous calls to web services called from Javascript.
  
  I'm implementing an enterprise CMS at my current job whose current interface is all DHTML, and keeps the right amount of state client-side between saves. The new version is built with XAML and is out of this world. My only fear with it is that it will lead to a new generation of horrible UIs as application designers starting making up their own visual metaphors like Flash programmers have been doing for the past 5 years.
  
  Charlie
  
  P.S. You come all the way to Toronto and you don't have time to swing down to DC to visit for a day? For shame. ;-)

  by Charlie on 2005-04-07 22:24:48

• I am serious about RIA's and I'd love to do everything in Flex. Since I work for a small company and do work on the side for a small company, at present I can't justify the time if I can't deploy Flex for the right price. Sure I can get half-way there by using a framework to separate out the presention from the application logic. But then, depending of the size the organisation, I'd have to either go with either Zinc for intranet applications or Flash/Coldfusion for intranet applications with remote access by a small number of users from a closed user group.

  by Chris on 2005-04-08 06:29:30

• Very interesting. But I read somewhere that we could mix up Flex with .NET platform. Do you have any informations on that fact? First, Java isn't supported everywhere in the middle enterprise market as .NET is (M$ everywhere, you remember?) and it's so heavy in terms of server ressources.
  
  I'm awaiting the Macromedia Press book on Flex, Developing Rich Clients with Macromedia Flex, from Amazon. It's suppose to be THE book on Flex at the moment. I hope I'll get some informations on this point.
  
  Thanks again for the great article.

  by Ards on 2005-04-08 19:50:33

• I've put up some of my thoughts here:
  
  http://www.darronschall.com/weblog/archives/000160.cfm
  
  The reason the C# solutions appeal to me more than ActionScript ones are because of the supplimental tools surrounding the C# languages.

  by darron on 2005-04-26 16:38:10

• Hi Raghu, The last time I evaluated Laszlo was about a year ago and we ended up going with a Flash-based solution using Grant's components (gLic/MCOM) -- a version of which will be in Flash 9. Today, I am very happy with Flex and cannot see myself using anything with a less-elegant workflow and programming model for RIA development, especially now that the Flex SDK is free. hth, Aral

  by aral on 2007-02-15 19:20:46

• Hi Aral, Thanks for such a nice article. We are evaluating RIA frameworks for one of the product development efforts. Your article is an eye opener. However, just wanted to know if you will still make the same opinion on Laszlo (given the fact that this article is dated 2 years ago and Laszlo had undergone lots of changes). Thanks, Raghu

  by Raghu on 2007-02-14 09:13:18

• [...] Check out the full post : http://www.aralbalkan.com/330 [...]

  by Trinix Web-(r)evolution » Blog Archive » A Summary of RIA Development Tools: Past, Present and Future on 2007-05-09 08:23:04

• A Summary of RIA Development Tools: Past, Present and Future... It’s hard to keep track of all the different frameworks and all RIA technology. But on this blog I found an interesting post of the list of the tools for developing RIA. Here a short list of the RIA mentioned: Flex Flash Laszlo NeoSwiff Xamlon P...

  by Trinix Web-(r)evolution on 2007-05-09 08:23:04

• I think you've made a typo here - plugins are the hack, designed to get Director animations to display on web pages when documents were indeed inert, dead lifeless objects. Now we have a live DOM in an EECMAScript container with fully featured events (if MS would pull it's finger out) and server callbacks there is absolutely no need for Flash to make web applications. There's still a case for using Flash for vector graphics where a raster would be too large but the utility of that is watered down by the need to devolve rendering control to the plugin banning you from adding discursive text except through the useability-breaking navigation-handicapping information-strangling plugin. When native SVG finally takes off and is available as a live DOM to the browsers ECMA script runtime along with the rest of the application the last excuse for using plugins for the power of vector graphics will have gone. The last excuse for using them to give the client the power of an application container, of course, went with AJAX. Sorry for the troll - been gradually getting sicker and sicker of marketing departments breaking CMS models with meaningless Flash apps just because they want contained fonts, and when I see the bogus claim that it's needed for client-side apps someones going to hear about it and you just hapenned to be standing on the blacktop.

  by Emyr Tomos on 2007-05-15 11:10:08

• Hi Emyr, Director and Flash are two separate technologies. Flash has allowed the creation of state-maintaining clients ("Ajax" style applications) since the turn of the century. I'm glad to see that JavaScript and HTML are now catching up to where Flash was seven years ago but, in the meanwhile, Flash has moved on. Do you honestly believe that you can create the same level of interactive applications that run exactly the same way cross-browser using SVG + JavaScript + HTML? Good luck! You can't. SVG was stillborn and will remain so regardless of what artificial attempts are made to revive it. It's more of an ideology than a practical technology. The key thing you're missing is that we've overcome the technology issues in Flash and have had lots of time to concentrate on building toolsets and workflows to make application architecture easier. Even if you could emulate the functionality of a Flex application using SVG + JavaScript + HTML, it would take you orders of magnitude longer to do so because of a lack of tools. Flash isn't going anywhere and it will not be replaced with a combination of SVG + anything anytime soon. I'd urge you to take a look at Flex and ActionScript 3 -- if only to get a glimpse of what JavaScript and HTML will be emulating next.

  by aral on 2007-05-15 11:22:16

• I've never given this a try, but I think it's about time I do.

  by Stephanie on 2009-03-16 20:55:18