degraded AJAX app + pre-loaded hidden java swing applet, the best deployment option for complex rich clients?

1) When AJAX isn't enough to address complex visualization or complex UI (or: there is no Java2D in javascript)

The trend is definitely to port traditional desktop applications to the web using AJAX. To overcome browser incompatibilities and javascript language flaws, we are using lots of frameworks including the Google Web Toolkit for instance. Those are fine but will only work well within a limited range of use cases as I will explain.

There is a use case indeed where AJAX+frameworks aren't enough: the case where you need superior visualization features like diagram editing or diagram driven modelling for instance (think about the equivalent of the Visio desktop app to model UML online for instance).

Ultimately, the point is that javascript in browsers doesn't allow you to dynamically draw a bunch of lines without consuming too much memory. Yes there are some attempts out there:

• based on div pixels
• based on transparent blended gif images (scales possibly a bit better)

but as you can see by yourself, those trick doesn't scale to dozens of animated lines, no way.


2) SVG applications fall into the same deployment trap as java: not everybody has got the required runtime platform

Then what? Oh yes, there are those guys that will tell you to use SVG. SVG is great indeed, but you know what, MS Internet explorer requires an external plugin (Adobe) to display SVG, so basically, your shiny SVG/AJAX app falls into exactly the same deployment trap than java: not everybody can run it because not everybody already has got the required runtime platform.


3) SVG+VML turns into a maintenance nightmare

Then what? There are those who will tell you: OK let's writte an AJAX app the will use SVG on Moz browsers and VML on Internet Explorer. Fisrt of all, unlike SVG, VML is an end of life product that's not that much powerful. And moreover, your AJAX/SVG/VML app has already turned one of those maintenance nightmares!


4) Then a java client is the best, even in 2006. But which one, webstart or applet?

So taking all this into account, the best target runtime for large deployment of complex visualization application is... JAVA. A good old one jre 1.4.2+ is already well deployed indeed and programming java is easy and best of all, java is a language able to handle the complexity.

Java? OK, but do you mean applets or webstart? Well actually I mean applets. While webstart is younger and got a better security sandbox, webstart won't allow you to integrate you application in the browser just like applets. And using all the DHTML browser facilities is very handy, especially in document centric applications like CMS or publishing tools.

Yes but aren't applet slow at startup? Well, yes they are. And you know what, that's almost normal considering all you can do with the java runtime (much more than Flash for instance). Also don't forget that applets are cached after the first use, so even if your huge applet first takes time to download just like any other web app, then only startup time matters.


5) Don't even wait for the applet startup, instantly popup a degraded AJAX app to handle the first user interactions!

OK, Javascript apps start a way faster than applets. So why not instantly popup a simple degarded javascript app to deal with the first user interactions while the heavy business logic is being loaded in a powerful hidden applet? After the applet is loaded, we swap the two and the user now plays in a full featured desktop Swing application...


6) Hidden Applet and degraded AJAX howto

I've read that some people advice to set the applet size to 1*1 pixel to hide it and then makes it larger to display it. However, unfortunately, it seems that this hack makes the resize quite slow in Firefox, giving the feeling that the app is unresponsive.

I've found a better way, style your Ajax Div container and Applet div container this way (using CSS) :
div.visibleAjaxDiv {height: none; overflow:hidden}
div.hiddenAjaxDiv {height: 1px; overflow:hidden}
div.visibleAppletDiv {height: none; overflow:hidden; visibility:visible}
div.hiddenAppletDiv {height:1px; overflow:hidden; visibility:hidden}

then switch the Ajax and Applet div class when appropriate (for instance when the user request a complex interaction in your Ajax app, after you checked that the applet has been fully loaded indeed).


7) Liveconnect as the glue between the AJAX app and the applet

What you want is that the applet will remember what the user first told you in the AJAX app (for instance the name of the diagram to be created) and you also want the AJAX app to remember what the applet told (for instance you hide again the applet after editing your diagram, but then you want the AJAX app to display the picture of the diagram when it has been uploaded...


8) Your applet needs to communicate with the server. XMLEncoder and XMLDecoder are a free lightweight persistence framework for your applet, but it requires some tuning to be used in an unsigned applet.

Hardcoding business object encoders and decoders is the best way to write unmaintainable and unnecessary code. Fortunately, java allows you to persist and read javabeans at no cost.

However, the DefaultPersistenceDelegate and Metadata java code suffer some flaws making them hard to use inside an unsigned applet (security exceptions and heavy network use), but fortunately, I found a workaround for both XMLEncoder and XMLDecoder, see those posts:

• hack for XMLDecoder
• hack for XMLEncoder
  

9) Conclusion

Yes this way of associating technologies seems a bit tricky and too novel for production use. However, I think this is the best available technology for complex visualization rich clients. Also, I don't consider it's more hacking than traditional AJAX frameworks. No it's not, most of this technology is traditional java programming, one CSS style sheet, two java classes to reuse and only a bit of javascript but less than a full blown AJAX app. Also, if several people start to deploy this way, we could build a framework and spread best practices. I think this is better than waiting forever that a better client runtime is widely deployed... All this is available now. Any comments will be very much appreciated.


10) An example?

Yes, I've got an example. Unfortunately, the degraded AJAX app is reduced to its simpler: only a clickable image launching the app, with a tooltip, image reloading and file save checking, but the Swing app is shiny and based on JGraph (the GPL version of JGraphpad). And it's not hard to follow that proof of concept and build a larger app following those guidelines.
see the example here: visualmodeller