Oh No! More Ajax

Ok, now things are starting to become ridicule. Ajax this, Ajax that... everything has to be Ajax-enabled to be considered cool. What else can they think of ? An Ajax operating system ? Well...yes :)
Welcome to the wonderful world of AjaxOS, a place where every file is free... I know I'm being a little sarcastic...but just hearing the name sounds a little silly, to say the least. But I don't blame them. At this time, the word sells, so it's a perfect way of getting attention.
Anyway, this new operating system is in fact based on the well known Linspire Linux distribution. What they did was to integrate web (ajax enabled web) applications into the desktop. As cited on their site:

By seamlessly integrating the power of web based applications with Linspire, ajaxOS recognizes any compatible file (doc, svg, odf, txt, xls, etc...) and launches the most up-to-date AJAX software from a Firefox browser.

Actually it can be a good idea if it works well. I'm not saying this will be the future, but it's an alternative that has a few advantages, like a small installation or the ability to open any file format without having to install first the corresponding viewer/player. In some cases, this might be useful, like public-access computers as it reduces configuration and maintenance effort drastically, and may even provide a better service (public-access computers don't usually have all the software one might need at some time).
Anyway, it's still not availalable yet. Let's wait and see...

Ajax toolkits

Well, it appears Ajax is here to stay. I've already used some Ajax-like features in some projects but nothing too big yet. The thing that I like less in Ajax is JavaScript....yes, I know that without it, it's not Ajax :)
However, my gripe with JavaScript is not unique...
Recently I discovered two new frameworks for dealing with Ajax and both of them minimize JavaScript code to zero! At least, from the developers point of view. These are Google Web Toolkit and ZK. Both of them are Java frameworks, and they hide all the JavaScript away from the developer. The idea is to create an event-driven framework filled with rich GUI widgets that resemble desktop apps. The thing I liked in both frameworks is how Ajax is put inside the framework and away from the developer. It's not a framework to build Ajax, it's a framework to build rich web interfaces, that is powered on the inside by Ajax. How is this done ?
In these kind of applications there's three parts: client-side code, server-side code and the glue to bind them. Client-side code has to be JavaScript (along with html, CSS, etc) for the browser to interpret. Server-side code can be in almost any language, but in this case, it's Java. The third and the hardest to accomplish is the communication between the previous two. Ajax provided us with a way to create that communication, but coding it by hand is complicated and troublesome (although interesting to learn). What both frameworks provides us to simplify these tasks are:
First, they provide a way of building the web interface that is more similar to the way we build desktop apps. They both provide a rich set of graphical widgets, typical of desktop apps (of course, inside, this is translated into something the browser understands ;)). Second, and more importantly, all communication to the server-side is done automatically and transparently. From the point of view of interface design, you layout widgets that have events. From the point of view of the server, you have a simple Java API that handles events. Everything in between is given by the frameworks and executed automatically. This way, server code is like a traditional desktop app: event-driven.
Despite its similarities, GWT and ZK implement this idea quite differently. In GWT you do everything in Java, even specifying the layout and widgets. But instead of compiling your java files with good old javac, you use a compiler provided by GWT. This compiler will translate the java code you happily wrote into JavaScript. This is basically creating JavaScript without actually writing it :)
In ZK you create the widgets and the layout in XUL and XHTML (actually ZUML, which in the future may also support XAML and XQuery). Then create the event handlers in Java to do the server work. Binding Widgets and event handlers is done in ZUML, and it's easy to do.
I still don't have an opinion of which I like more. At first sight GWT seems easier to work with, but I'm always suspicious of generated code. ZK seems more flexible and it's based on several interesting technologies, like XUL. I believe both can have success, but I'm pretty sure the name google will show its weight, at least at first ;)