Flex News Desk
Rich Internet Applications - State of the Union
What's your technology choice for implementing RIA?
Feb. 10, 2008 11:15 AM
[This prescient article first appeared on SYS-CON.com nearly 12 months ago.]
We are entering an era of Rich Internet Applications (RIA), and many enterprise development managers are facing the dilemma - which way to go - remain with tried and true Java or .Net technologies or less known yet AJAX, Flex, OpenLaszlo or a number of other vendors. This article is an attempt to give a brief overview of what's out there on the RIA market.
Historically there have been major shifts in the software industry. We moved from mainframes with dumb terminals to client/server. Users gained in convenience and productivity, and mainframe systems were patronizingly labeled as legacy. With the availability of the World Wide Web industry visionaries turned the tables: vendors and corporate IT had been eager to get rid of the complexity of client/server version management and technologists were sold on multi-tier computing. This time client/server was called legacy. Excited with server multi-threading, messaging, persistence, and similar toys, we pretend not to think that, at the end of the day, we'd have to trade user experience and productivity for the transparency of application deployment. And to make us feel better, we proudly called the new breed of applications "thin client."
Now we are entering an era of RIA, which restores the power of desktop applications...inside downloadable Web page. RIAs run in a virtual machine (i.e., Adobe Flash Player or Java VM) and have the potential of becoming a full-featured desktop application soon. As opposed to just simply displaying Web pages delivered from some server machine, RIA really run on the client. Many of the data manipulation tasks (sorting, grouping, and filtering) are done locally like in the old client/server days. In three or four years most newly developed projects will include RIA technologies.
A rich Internet application combines the benefits of using the Web as a low-cost deployment model with a rich user experience that's at least as good as today's desktop applications. And, since RIAs don't require that the entire page be refreshed to update their data, the response time is much faster and the network load much lower. Think of a globally available client/server application.
Let's illustrate the difference between "legacy" Web and RIA with a shopping cart example. Non-RIA Web applications are page-based. Since HTTP is a stateless protocol, when the user moves from one page to another, a Web browser doesn't "remember" the user's actions on the previous page. As a common treatment of this "amnesia," a user state is stored on the server side in the form of the HTTP session.
Consider the case of an online shopping session. It can go as follows:
1. The user initiates a search for an item on Web page #1.
2. The server processes this request and returns page #2 that may (or may not) contain the required item.
3. The user adds an item to a shopping cart that takes yet another trip to the server to create the shopping cart and store it on the server side. Then the server responds with page #3 so the user can either continue shopping (repeating the first three steps) or proceed to the checkout - page #4.
At the checkout the server retrieves selected items from the session object and sends page #5 to the user for shipping info. The data entered travels back to the server for storage, and the client gets back page #6 for billing information. After that page #7 will confirm the order and only then goes to the order completion page.
This simplest of online purchases consisted of seven roundtrips to the server. In striking difference to desktop applications, a few-seconds-per-page refresh is considered fast(!) for a typical Web application, and the commonly acceptable delay is up to eight seconds. Is the user motivated enough to complete the purchase? Think again, because your system gave him a chance to reconsider seven times in a row. Now assume that the network and/or server are slow...your potential customer went elsewhere.
Rich Internet applications eliminate the roundtrips and substantially improve system performance by doing a lot more of the processing on the client than a thin client Web application. Besides, RIAs are stateful: they accumulate the information right on the client! To put it simply, RIA isn't a set of pages controlled by the server; they are actual applications running on the client's computer and communicating with servers primarily to process and exchange data.
Both consumer-facing and enterprise applications benefit from being RIAs. It's a well-known fact that e-commerce Web sites such as online ticket reservation systems and online retailers are losing revenues because users abandon shopping carts on non-responsive Web sites during the checkout process. Such Web sites result in lots of calls to the call center, a major operational expense in and of itself. The performance of any system operated by employees is critical to company productivity and RIAs provide a performance boost over HTML applications, while reducing operating and infrastructure costs.
RIA Platforms: The Major Choices
There's more than one way to create RIAs that run in the client's browser with the help of some kind of client engine. These are the most popular products or technologies:
- A Java programmer can create Java applets. As mentioned, this solution has been available since 1995.
- Using Adobe Flex you can create an ActionScript application for the ubiquitous Flash Player, a high-performance multimedia virtual machine that runs bytecode files in the SWF format (pronounced swif). The player's JIT compiler converts the SWF bytecode to native machine code for fast performance. The later facility is specific to Flex 2, available since 2006. Although early versions of Flex were out in 2004, they didn't support just-in-time compilation.
- Microsoft Windows Presentation Foundation (WPF) was released as part of .NET 3.0 in November of 2006 and can be used to create both Internet and desktop applications (it also has the Everywhere version - WPF/E).
- AJAX, a k a DHTML, born circa 1998. This solution was recently boosted with XMLHttpRequest API support for all major browsers. AJAX served as a wake-up call for the user and developer communities. It is often the first step on the migration path from the legacy Web to the world of RIA despite being seriously handicapped by having to support browser incompatibilities and a poor programming model.
Ajax_is_a_hack commented on 23 Feb 2008
Hey Yakov, check out this:
OpenLaszlo - yeah, it's an *alternative*, but let's be honest--other than it not being backed by a major commercial developer (which many see as a good thing)--it doesn't have Flex beat on much of anything. (Flex is open source too...) I've read some other admittedly less biased comparisons and OpenLaszlo was graded lower I think in every category.
jeff_s commented on 11 Feb 2008
This blog is certainly not an unbiased analysis, even though it's pretending to be just that.
The article is basically "Flex rules, everything else drools".
It goes on and on about the good things about Flex, while giving only cursory coverage of Flex drawbacks. Meanwhile, it's just the opposite regarding the other technologies, going on and on about drawbacks, and giving only cursory coverage of advantages.
Case in point, Yakov says that Java Swing development is "hugely expensive". Nonsense. First, NetBeans is completely free, and NetBeans has the wonderful Matisse GUI designer, making the development of great looking Swing UIs a snap. Second, there is JavaFX, which is an XML based declarative scripting language that is used to quickly build rich Swing UIs super easy, and is very similar to MXML/Action Script, as is featured in Yakov's beloved Flex. Third, there is a plethora of third party libraries and controls in the Swing ecosystem, that further extends Swing capabilities, and makes Swing development easier.
Then, Yakov fails to mention how expensive Flex Builder is (which, to be honest, you'll need to be truly productive with Flex), to the tune of $249 (as opposed to Free for NetBeans).
Yakov also completely fails to mention how much of a CPU hog Flash can be, especially on older/budget machines (which, let's face it, are quite common in the business world). So if you do a RIA with Flex, which is running in the Flash VM, you're going to get a lot of end users (corporate workers) complaining.
Flex is quite good, and has it's advantages and disadvantages. Same with the other technologies mentioned in this article.
But Yakov's article is completely biased in favor of Flex. That's fine, as Yakov has long been singing Flex praises. But he's presenting this article as a fair analysis, when it's anything but.
Thus, anyone reading this article should take it with a grain of salt.
Sebastien, not only I've mentioned OpenLaszlo in the article, but I also published my interview with the creator of OpenLaszlo:
Am I cleared now or should remain ashamed?
It's such a shame that you don't even mention OpenLaszlo as an alternative for Adobe Flex...