Each day as an AJAX developer seems to bring another helpful revelation: a new tool, a new gadget, a new way to reinvent the browser. But even when I'm confronted with a breakthrough as big as Firebug - the brilliant debugging tool for Firefox - in the back of my mind I'm reminded that the AJAX state-of-the-art is trailing behind the debugging tools that we've had in Java for years. With age comes maturity, and with Java's maturity has come a wealth of development environments, field-tested frameworks, and a rich set of strongly typed APIs.

In my current company, we all share a background in enterprise Web development. Our primary goal has always been to take the most innovative user interface technologies and massage them into a form that new programmers can feel comfortable with, no matter the underlying platform. Although I have significant experience in both Java and AJAX client development, I'm reluctant giving up the maturity of the former just to achieve the pervasive reach of the latter.

Today, our goal is to bring the power of an event-driven Web - one that breaks away from the request-response patterns ingrained over the last 10 years - to the largest possible development community.

High Stakes Development
To that end, my peers and I built technology to bring real-time AJAX development to Java developers. Our core technology is the Chai virtual machine that allows Java bytecode to be translated down to the browser and run without any plugins or setup. Other projects such as the Google Web Toolkit (GWT), Java2Script, and Script# take a similar translation approach. Even though the focus differs, these projects share a goal of allowing developers to write AJAX applications in their familiar development environment and language, and let the framework or virtual machine generate the corresponding JavaScript. Why does this approach work so well for AJAX development?

• AJAX applications generally are impressive not for what they do, but for where they do it. As amazing as it has been to see mapping tools, photo browsers, and chat clients running in a browser, these applications have been running just fine as native or Java clients for many years. There are many more skilled Java and .NET developers across the world that can write such applications in their frameworks than there are skilled AJAX developers. Although an elite few have the skills required to craft AJAX applications by hand, a much larger majority would love to apply their Java or .NET expertise to browser-based clients.
• Using a translated JavaScript client rather than a hand-coded file frees the runtime code from the constraint of being human readable, thereby increasing the opportunity for optimizations.
• Similarly, server-side translation allows for a single source of truth that can target and adapt to the differences in browsers. Although client-side frameworks can also do this, they can incur an overhead for executing through a runtime.
• Why partition your developers across tiers? If your server team already has the knowledge of your communication protocols, let them work on both ends of the pipeline. They can implement both using the Java they already know, even if the client side is translated to JavaScript.

To demonstrate these benefits, we had approached SYS-CON Media with the idea of building a showcase application for its upcoming conference, AJAXWorld Conference & Expo, based on our translation product. We agreed that a Texas Hold'em poker game would be a great way to deliver in real-time to a conference audience. Unlike the standard stock quote ticker demos, a poker game gives users a hands-on way to see their own actions reflected in real-time across the screens of their eight competitors, and potentially hundreds of viewers. Using our translation technology, it was feasible to quickly build a poker application that would look great in the browser, even if the coding was done via Java and with our familiar tools.