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
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.
I disagree, fundamentally. Web 2.0 (I hate the term) is still - if done properly - the same as Web 1.0. For example, a website should be built to work properly without any fancy Ajax stuff, and only then it should be added where appropriate.
A web application is not an alternative (and worse) way to build an application client - it's architecturally different and has significant advantages in terms of evolvability, maintainability, integration and so on.
I agree, though, that those who equate Ajax and Web 2.0 with "apps in the browser" are mostly creating problems, not solutions :-)
Posted by Stefan Tilkov on September 27, 2006 at 12:58 AM CEST #
Hi,
you make some valid points but take a look at the languages these "Web 2.0" (hate this term too ;) apps are written in. Its mostly PHP, Python, Ruby etc. These developers dont want to write them in Java/.NET etc. And try to explain them what advantages they get from using JWS etc.? Actually there are none! With JWS and different JRE versions you have the same problems with incompatibilities/differences etc.
Due to all the security issues lately most users actually keep their Webbrowser up-to-date and using some JS framework (e.g. dojo) you have (usually) absolutely no issues with different browsers. Your "App" will look exactly the same on Windows, Linux, Mac, Solaris etc. and all the user has to do is to enter an URL into his Browser.
If in some time *every* machine in the world will have the same JRE with the same GUI Framework it may be an alternative, but right now its NOT! And thats why this "Web 2.0" stuff is so successful right now, because it simply works FOR THE USER (they dont care about the developer ;)
Bye,
Thomas
Posted by Thomas Pietrzykowski on September 27, 2006 at 04:45 PM CEST #
Thomas,
we have to differentiate between intranet and internet environment. In intranet it should be possible to provide a compatible platform and defined JRE or .NET version.
So AJAX is valid, but only in case the deployment and installation of "real" rich clients becomes to expensive. Otherwise it is only a nice "browser hacking"
Posted by Adam Bien on October 01, 2006 at 03:21 PM CEST #
Stefan,
"I disagree, fundamentally. Web 2.0 (I hate the term) is still - if done properly - the same as Web 1.0. For example, a website should be built to work properly without any fancy Ajax stuff, and only then it should be added where appropriate."
>absolutely. I do not mean the increase of >usability using async communication or partial >updates. What I meant here are frameworks which
>try to "hack" the browser to be a rich client.
so, I fully agree with you :-)
Posted by Adam Bien on October 01, 2006 at 03:24 PM CEST #