Jaxer and GWT both address the question of how to unify the development paradigms across client and server. But they take very different approaches, at least to the UI part of web applications. GWT appeals to developers who would rather not write HTML or JavaScript at all, and instead have it generated automatically from their Java code. With GWT the developer writes server Java code for to describe the UI, and GWT autogenerates it. Jaxer appeals to those who want to write the HTML and JavaScript themselves, use any combination of Ajax libraries, and be in complete control of what appears on the user's browser. With Jaxer the developer writes the UI as they desire, in the familiar Ajax way, and designate certain parts to run on the server.

With GWT you end up writing pure Java for your entire application, except if you want to take more control of your UI than what GWT offers for you out of the box, in which case you end up mixing Java, HTML, and JavaScript, and you're back to the issues Jaxer and GWT were trying to solve.

With Jaxer you end up writing pure Ajax (HTML and JavaScript and CSS) for your entire application, except if you want the back-end of the application to be in Java (or some other language). But Jaxer will natively support connectivity to Java and other languages, beyond the network-layer (web services) integration already in Jaxer beta. So you will be able to keep your entire presentation layer in a single paradigm — Ajax — and have your business logic layer in Java. And since the interface between them will be on the server, you will not be forced to expose your Java APIs as web services on the public internet.