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 ;)