Ajax is an odd beast, because it gives a very rich user experience when compared to a traditional web page (Yakov writes wonderfully about this at http://java.sys-con.com/read/163232.htm), however apart from that it’s hard to figure out what is so great about it.  Good technology wins in the long run because of tooling (something Microsoft know and excelt at), so what is the lure of Ajax ?  I think it’s simply that it allows logic be put in one file – in your HTML (or servlet, JSP, ASP or whatever kicks out HTML) you write your server logic and your client logic together.  They get versioned together, a single developer codes them in the same thought thread, and logic is organized in encapsulated way.  Fancier architectures with remote objects and clients talking to back ends often have almost parallel development processes requiring some kind of technical and process glue.

However, flashy Java script however has been done for a while – IBM Research used to have a neat project, now retired, called Sash that created very rich client GUIs with JavaScript, including its own cross platform SDK and WYSIWYG tooling.  The reasons Sash failed will surely be thrown in Ajax’s path – browser script incompatabilies with new releases and platforms, problems debugging and tuning applications, and so forth.

What worries me is that Microsoft have had active server pages for a long time now and .NET forms, where the server and client code just get written side by side.  You just brace your code with whether it’s VB script on the server or on the client, and you get a very rich experience.  You’re also proprietary to the Redmond machine though.

I view Ajax now as a dumbing down of things, because the delta between using Microsoft tooling and Ajax and some kind of J2EE one isn’t wide enough.  Microsoft tool their stuff better in the long run (they have lots of money and very clever dedicated people).  What we need to do for Java is to recognize the problem, which is basically that client server should be coded in a simple way (without multiple files and artefacts to manage to get a single functional task done), and that the client runtime experience should have nice async stuff that makes it not batch oriented.  However it should be richer than JavaScript – perhaps JDNC could step up with a set of async comms libraries, maybe Eclipse RPC could do it.  Java has a lot of big server clients, including eBay and others, who need to get to the next level of killer app to keep their client base as their competitors play catch up.  Java needs to be there, and it’s an opportunity we need to step up to and lead rather than follow.  It worries me the amount of cycles we’ve spent in the last few years dealing with old paths such as widget toolkit wars without having a good client server architecture that addresses the middle part of the equation rather than both ends and then gluing them.  We need a single file solution but, unlike say JSF, it must be one that doesn’t just spit out HTML or HTML + some magic spells for the browser, but one that spits out something that the client will interpret and create a fully fledged Java GUI that is super light, has good frameworks for using async protocols for validation and bleeding in data, and has first class tooling for.  My favourite for this would be some kind of cross between ULC (www.canoo.com/ulc), combined with a JNLP delivery or small OSGI runtime client components, and using SWT to get a lite client runtime and high fidelity user experience.