Kevin Whinnery's Blog

In the world of Rich Internet Applications, there is no shortage of technology choices to compose a user interface. But what tools will give us the best bang for our buck? Here is a look at some heavy hitters and newcomers in the RIA market, including: HTML & AJAX, Rails and Grails, Flex, Silverlight, Curl, GWT, OpenLaszlo, and Appcelerator.

When you set out to build any application, difficult decisions must be made about the frameworks and technologies you will employ to get the solution built.  In the world of Rich Internet Applications, there is no shortage of technology choices to compose a user interface.  Within reason, any technology can be used to create any kind of user experience - just ask the JavaScript wizards at Google or 37signals. 

But not everybody has that kind of talent (or time and resources) at their disposal, so the rest of us have to decide what level of user interface quality we are gunning for, and what tools will get us there the fastest with an end product that is maintainable (read: what tools will give us the best bang for our buck).

This is a question I grapple with often, and I took a few minutes (brace yourself for some outstanding MS Paint skills) to sketch out where I think some heavy hitters and newcomers in the RIA market stand when the complexity of the solution is compared to the overall feature-richness of the UI:

 

Graph Plotting Complexity vs Feature-Richness of the UI

From my experience, a traditional HTML + Ajax application can create great results, but maintaining even a modest JavaScript codebase with intermediate level JS programmers is a total nightmare.  Successful JavaScript-heavy apps require a very talented team to develop and maintain them, and even then, the tools are only now coming around to a point where that kind of effort is productive.  So applications built on standard MVC-ish frameworks (Struts, Ruby on Rails, Grails, Spring Web Flow) get complicated (and expensive) fast depending on how much client-side programming is necessary. 

But at the lower levels of UI complexity, those frameworks offer some great value, especially Rails and Grails. When an application's content consists largely of dynamically generated documents, HTML and AJAX can generally get the job done nicely.  After all, displaying documents is what HTML is all about.

But as requirements call for a more expressive UI (which requires more client-side logic to be written), the old way of writing web applications breaks down quickly.  The browser was never intended to function as an application platform, and it starts to show as an application requires more asynchronous data access, fluid and responsive control, and event-driven user interface. To counteract the stateless nature of the web, we start to invent contrivances like "page flow" and abuse the HTTP session.  We find that our runtime environment on the client is not consistent because of the different browsers in the marketplace, not even between versions from the same vendor.  It is at this juncture that we reach the breaking point of the browser as a means of creating application UI (marked at point A on the graph).

At this point it becomes clear that we need to move away from the server-centric programming model we are used to on the web to more of a client-server architecture.  To effectively create advanced user interfaces we need to be able to track UI state on the client side and make our UI event driven.  At first, it seems inevitable that we leave behind the open, standards-based world of the web (and all our hard-earned skills surrounding it) for a more consistent runtime environment, like the Flash player (using Adobe Flex), Microsoft's upstart Silverlight platform, or some other more exotic solution, like the B2B-targeted Curl platform.

But before abandoning the browser, we still have options.  A number of emerging frameworks seek to tame the browser and make it a suitable platform for a rich client application.  The biggest fish in this pond is currently Google Web Toolkit (or GWT), which allows developers to write UI code in Java and have it transformed to JavaScript that will run in the browser.  All this with all the development tools and skill sets that exist out in the marketplace today surrounding Java. Sounds great doesn't it?

It sure did to me, until I started to actually write a UI in straight up procedural Java.  I was shocked at the volume of code I had to write to assemble even the most basic UI.  Also, trying to read a collection of Java classes and visualize the structure of the UI was, for me, not an easy task. On top of that, it was unclear to me how a design team would effectively collaborate with a development team, especially when they are speaking different programming languages (Java versus HTML/CSS).  The lack of any kind of markup language to accompany Java in GWT hurts it badly - and the alpha-stage markup language extensions that I see coming out seem all too far away.

OpenLaszlo is an option, as LZX can be compiled into DHTML/JavaScript for the browser, but it carries with it all the new language overhead of Adobe Flex, without all the nice features like a polished set of widgets out of the box and seamless design to development workflow via Adobe CS3.  Yes, it does run in the browser without a plugin, but it's going to run a ton slower than the same application written for the Flash Player.  Overall, I see few advantages to choosing OpenLaszlo over Flex.

But as you can probably tell from the graph, I think there is a worthy competitor in the 'RIA for the browser' struggle in Appcelerator.  Appcelerator pushes the browser beyond Ajax by providing a client-server programming model and providing event-driven UI.  It accomplishes this through what I categorize as a brilliant innovation, which is its Web Expression Language and messaging system.  Lightweight messages and JSON data payloads govern communication between elements on the page and server-side services alike. Data marshalling and unmarshalling is accomplished by the framework, which saves a common point of tedium in RIA development.  Appcelerator also uses HTML and CSS to structure UI, so your designers and developers can work in concert as before.  Appcelerator pushes the breaking point of the browser out even further (I marked this at point B on the graph above), because it provides you with the essentials for developing a rich client without abandoning the browser as an application platform.

But there comes a point where user interface requirements demand more than can be provided by the browser (at least easily).  When an application UI demands the use of diverse media sources, advanced animation, top-quality client side performance, and retrieving and working with many thousands of rows of data, the browser simply cannot perform as well as the Flash Player plugin, which means programming in Adobe Flex and ActionScript 3.  AS3 is a powerful, strongly-typed object-oriented language that provides you all the related advantages. It is also compiled and run as byte code in the Flash Player, so it will often provide client side performance advantages over JavaScript (which is of course interpreted). There is also support for a binary data transfer protocol that is the fastest way I know of to get data into the browser. Last but not least, designers can achieve pixel-perfect results by using CS3 creative tools to create Flex UI components.

All this power comes at a price, however.  The tool set is not cheap, and Adobe Flex skill sets are not exactly abundant in the marketplace.  The event system is nowhere near as elegant as the Appcelerator solution, and the syntax of MXML/ActionScript can get a little verbose.  You are also relying on a browser plugin, and while the Flash Player's penetration is deep, I have already come across clients where Flash Players are not installed on modern machines.  Some corporate environments may even prohibit browser plugins.

But Flex, for my money, is hands down the most powerful option for creating RIA on the web today.  I would consider it a 'nuclear option' reserved for graphically intense, data-access intensive, or desktop-like UI requirements, but when you need to break out the big user experience guns or take advantage of the high-speed AMF protocol, Flex is going to be your weapon of choice.

So there you have another lengthy teatise on the state of the RIA union.  With any luck it will be my last truly lengthy one for some time.  I look forward to any comments, and good luck to any embarking on a new RIA adventure...

AJAXWorld 2008 West Call for Papers Is Open! Submissions deadline: May 31, 2008 Next October's Conference is already receiving higher-caliber submissions from all over the Rich Internet Applications ecosphere. The theme of this October's AJAXWorld Conference & Expo 2008 West is 'Beyond AJAX to the RIA Era' and the Call for Papers, which is now open, specifically encourages submissions from exceptional speakers with high-quality use cases of the fast-emerging RIA alternatives. Submissions featuring such use cases as well as on dozens of other RIA topics have already begun streaming in to AJAXWorld Conference & Expo 2008 West, being held in San Jose, CA, on October 20-22, 2008. Click here to submit your speaking proposal today !