adam bien's blog

The Day After AJAX 📎

Asynchronous Java And XML is a set of interesting "hacks" which enables us to build almost rich (Swing or .net are still "richer") clients in a browser. Because of incompatible browsers, we have still to deal with different workarounds for each target platform. It is nearly impossible to do it without frameworks, so millions of AJAX frameworks help us to encapsulates the "if-else" statements.
There are client- and serverside UI-elements available. The clientside frameworks care about the communication between widgets (events, mediators), rendering and partial page updates. The serverside frameworks generate client-side JavaScript and realize validation etc.
Frameworks like DWR (Direct Web Remoting),  are very similar to RMI, SOAP or IIOP. JavaScript widgets are able to invoke serverside facades. The JavaScript Object Notation (JSON) can be compared with XMLEncoder or Decoder or the serialization mechanism in Java. It is a very efficient JavaScript Object serialization format. On the other hand frameworks like dojo, allow us to store data locally in a browser and provide event mechanism.
Most of the AJAX applications now use polling to track the serverside changes. The is already a notion of pub/sub model and client notification model available.

From the architecture perspective everything, which is mentioned above, is already available in the standard Java SE package. The Java SE 6 will provide the following features out-off-the-box:
  • Built-in lightweight database (JavaDB, actually derby). So clientside storage is easy to realize.
  • Client and serverside lightweight SOAP engine (can be used for callbacks)
  • Swing will be more integrated into the OS
everything else is already available with Java SE 5 and Java EE 5 for the server. The event mechanism for the client-server communication can be easily realized with JMS-topics.
From the architecture-perspective AJAX is nothing else, than reinventing the wheel in browser or simulation of native clients with more effort, many frameworks and actually no mature development tools (compared it with matisse, eclipse, netbeans tooling in the java space). The responsible AJAX or architect or developer should answer one quesion: Why?
There is only one reason for hacking the browser to behave like Swing:  JRE, jar deployment issues. Until now, you cannot expect from internet users to download JRE to run an application. Building AJAX application is easier for the end-users in this way.

But for intranet applications it is not a big deal to deploy Swing with Java WebStart or other JNLP tools.  WebStart infrastructure, allows deployment of applications, which greately exceed the capabilities of AJAX or other browser-hacking technologies (to justify hacking: just thing about the back-button issue -> browser were not designed to be a fat client platform), is easier to develop and MAINTAIN.

So the decision for using AJAX or not is simple. Is deployment of the JRE (15 MB) an issue or not? If it really is, use AJAX; otherwise Swing, .NET etc.

But: GoogleEarth (also 14 MB) needs to be installed natively - and almost everyone use it :-).

Are Java/.Net Fat Clients the future of "WEB 2.0": so WEB 3.0? :-)
We need only someone who introduces a soundful name for applets or swing, and a push from the industry.