The Elusive RIA
Posted by indroneel on March 31, 2007
Nine years and several technologies later, rich Internet applications are yet to attain maturity. Though AJAX and Flash have become widely accepted as the latest technologies for building RIA, these are far from being perfect solutions. This article presents a summary of the common problems that have assailed RIA development across successive generations of softwares and platforms.
The early RIA platforms, viz. Java applets were resource hogging behemoths. The introduction of swing-based applets and newer versions of the Java platform only compounded this problem. Loading a swing applet using JDK 1.2 plugin on Internet Explorer 5.0 used to add around 15 to 25 MB to the application memory for a basic payload. On JDK 5 this value increased to anywhere between 50 and 70 MB.
The more recent AJAX-driven interfaces fare no better than their applet counterparts. The usual memory load due to a UI of medium complexity can vary anywhere between 30MB to 70MB (not to mention memory leaks and unoptimized implementations).
The figures mentioned above may not seem very large if you are using a Vista-grade machine, but on an entry-level Pentium 4 with 512 MB RAM (the kind used by many home users) the results can be quite sluggish. Expect the system load to be even higher as the list of RIA platforms is expanded to include Windows Presentation Foundation and .NET 3.0.
Network Latency and Bandwidth Usage
The client-side implementations of a rich application usually add up to a significant size, even after major optimizations. This translates to larger startup times on slower networks. Progressive application loading and lazy instantiations can reduce this delay at the cost of reliability and higher bandwidth usage over a prolonged period of time.
Even at steady state, the bandwidth usage of a rich user interface tends to be higher than that of a conventional Web-based interface. This is mainly due to the concurrent nature of RIA that allows, and encourages, the execution of multiple operations (e.g. refresh, update and commit) in parallel as background/ancillary tasks.
Clearly, browser independence for RIA is no better than that of plain Web-based interfaces. The situation is in fact worse, as most of the browser anomalies become evident while working with complex and extremely dynamic screen implementations.
Recent technical offerings in the form of Google Web Toolkit and Apollo/Flex by Adobe provide more homogeneous platforms for RIA development. These platforms highlight one set of related languages (usually Java and XML) to define only the structure and behaviour of different user screens for the application. All the other layers (client-side presentation and data exchange) are abstracted out, usually through automated code generations and framework-level encapsulations. But these are evolving solutions that are not a best-fit for many enterprise scenarios.
The next generation RIA platforms, like Windows Presentation Foundation and Apollo/Flex are promoting development using proprietary technologies (.NET and Flash respectively). While the runtimes for these platforms are freely available, the corresponding development tools aren’t. This may serve as further impediments, opposing the spirit of free development that is an inherent characteristic of the Web.
 A Wikipedia definition of Rich Internet Applications.
 Migrating applications from Internet Explorer to Mozilla highlight the differences between these two browsers in terms of standards adoption.
 Rich Internet Application Mountaineer, a blog maintained by Ryan Stewart.