Bart Guijt's Purpleware

Bart Guijt's Purpleware

about Me and My Technology

Bart Guijt's Purpleware RSS Feed
 
 
 
 

The case for RIA technology from a Java developer perspective

The market for RIA toolkits is changing quickly – like three years ago we didn’t even know what it was, right now we are slapped around the ears with terms like Rich Content, Widgets, Realtime Ajax communication, Single-Page Interfaces and whatnot. A few years ago we were quite satisfied with Apache Struts and a bit fiddling with HTML, CSS and Javascript, now we are spoiled by the choices we have in all kinds of Web-UI frameworks, not knowing which one to choose for the problem at hand.

For this post we will make the case for RIA technology and why you should use it. In a following post we will discuss several RIA toolkits which are specifically suited for Java developers.

What is a RIA toolkit?

First, let’s make sure we understand the technology correctly. According to Jeremy Allaire, who wrote the first whitepaper on Rich Internet Applications, these are the most important characteristics of a RIA toolkit:

  1. There is a runtime platform involved on top of which the actual application runs (like e.g. the Java VM and the Flash Player);
  2. It provides a library of visual components (e.g. Input fields) and non-visual components (e.g. for Events and Ajax remoting), which are extensible as well;
  3. It is capable of communicating with (the originating) webserver, by means of XML-RPC, JSON, SOAP (or whatever) remoting technology;
  4. Applications for this platform can be used online and offline;
  5. It provides for easy distribution (almost always by means of a browser);
  6. An IDE or IDE-plugin is available to aid in UI design, wysiwyg style.

These characteristics are summarized with Macromedia Flash MX (an Adobe Flex predecessor) in mind. Furtunately, these are generic enough to be applicable for all serious RIA toolkits available today.

Why would you use a RIA toolkit?

Most web frameworks built on the java Servlet API seem to struggle a great deal to keep all parts of a Java webapplication together. The Java application is a messy collection of XML configurations, Java classes and HTML templates which are magically glued together by the framework: Apache Struts, SpringMVC, WebWork, JSF etc. are all examples of that mess.

All parts are glued together by configuration files and framework rules, so the relationships between the parts are hard to follow, especially for Java developers who are used to the statically-typed nature of the java language: Code Completion in the IDE, and specific messages from the compiler are features mostly absent when it comes to web development.

This mess is emphasized by the fact that we need to write the HTML, CSS and Javascript by ourselves. While the web frameworks might contribute some JSP taglibs, we still need to have serious HTML skills to get a job well done.

Next, we need to deal with the nature of HTTP: we need to manage the request/response cycle. Fot this all web frameworks apply XML to configure a so called Finite State Machine, describing the way a user ‘walks’ through the application. Fortunately we found out that this is equal to the GOTO statement in Basic, and we all know what Edsger W. Dijkstra wrote about that forty years ago.

Additionally, the HTTP request/response abstractions need to deal with scope issues as well: a particular piece of data, is it valid in a single request, session, application, user or server scope? It is too easy to make big mistakes here.

Finally, we need to consider the myriad of browser incompatibilities, air-tight security and greased-lighting performance.

Using a RIA toolkit we can eliminate almost all issues mentioned above: the application runs entirely on the client, and doesn’t need to disturb the webserver for each and every mouseclick to determine what to do next. The webserver is exclusively used to obtain resources (HTML, CSS, images, application files) and to provide web services.

Additionally, a RIA toolkit provides lots of widgets and layout managers which simplify the construction of a GUI, and solve browser differences at the same time.

Eventually, the end user gets better apps with RIA technology, which are built faster and more easily by the developers.

To be continued: A following post will discuss several RIA toolkits suited for Java developers.

[Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]

Leave a Reply

Activity Stream

RT @Werner: War is God's way of teaching Americans geography - Paul Rodriguez /via Randy Katz

Friday 7:32

Getting my eyes wet due to school achievements of my sons. They remind me of their father in completely different ways. Proud!

Thursday 10:01

iPad spin-off: e-reader, ipod, iPhone apps, browser, email, iWork; HP Slate spin-off: I run flash. What?

Thursday 8:08

Just found out about #Cufon. Seems way nicer than #sIFR, just for the fact it doesn't depend on #flash.

Wednesday 13:41

I see. "Web Indexed DB" is supposed to supplant Web Database in the long run due to SQLite dependencies - see http://bit.ly/aIKshA #html5

Wednesday 10:04