The best uses of Ajax so far have been usability enhancements to applications built on more traditional server-side architectures. For instance, caching and pre-fetching data on the client can reduce an application's perceived latency, a technique employed by some browser-based email clients and discussion forums. And, in general, not having to reload an entire page for small changes to delegate to the client improve usability.

At the core of such uses of Ajax is the requirement to make communication between the server and the JavaScript running in the browser both efficient and easy to code. Among the most promising and popular tools for that purpose has been the Direct Web Remoting (DWR) toolkit.

The DWR project posted this week the release candidate of DWR 2. An interesting aspect of DWR is that it provides two-way communication between JavaScript and server-side Java code, making it easy to control browser behavior from the server. DWR 2 makes server-to-client communication even easier:

DWR supports 3 ways to asynchronously transfer messages from the server to the browser: Comet (long-lived HTTP connections), Polling and Piggyback. Of these Comet and Polling are active (fast but require extra network traffic) and Piggyback is passive (slower but doesn't need extra network traffic). DWR automatically selects the best method transparently to the programmer.

WR takes care of Comet and polling, of distinguishing multiple windows in a single browser, and of fixing bugs in IE.

Other uses for this technology include progress bars, online games, stock tickers and any system where server state changes and we need to push updates to a browser or browsers.

Another DWR 2 feature is the ability to create JavaScript proxies in Java code. That makes it possible to use the supported JavaScript libraries—their proxied equivalents—from Java IDEs:

DWR can dynamically generate JavaScript from a Java API. This is done at runtime rather than compile time, so we can use it to remote control many browsers... Messages are sent to clients using Reverse Ajax.

DWR currently features Java APIs to Script.aculo.us Effects and DWR's own DHTML library:

import org.directwebremoting.proxy.scriptaculous.Effect;

Effect effect = new Effect(aBrowser);
effect.fade("id");

Finally, DWR provides more security features to protect against cross-side scripting attacks:

Two of the the biggest generic dangers to Ajax applications today are Cross-Site Scripting (XSS), which most people are aware of, and the new tool in the hack-box: Cross-Site Request Forgery (CSRF). DWR helps you protect your site against these attacks by providing automatic protection against CSRF attacks for many configurations, and by defaulting to a mode where XSS attacks are reduced.

Client-side JavaScript libraries, such as script.aculo.us and Prototype improved a lot in the past year, both in terms of features and in cross-browser compatibility. Creating Java proxies for some of those libraries seems like a good way to make coding with those libraries easier. However, that proxied approach is just one of many roads to Ajax—the Google Web Toolkit, for instance, takes the approach of providing a subset of the Java APIs to code with, and treats JavaScript as an assembly language a Java-to-JavaScript compiler outputs at development time. Of course, that output may well take advantage of Prototype or script.aculo.us. [See Artima's interview with Bret Taylor about the Google Web Toolkit.]

What approach to Java-to-JavaScript bliss do you prefer in you projects?