We’re having an internal discussion on the editor’s list about JavaOne news and mood, and there’s a thread on AJAX that I think is remarkable because it’s based in profound misconceptions. I’m disagreeing with everyone here, first with two of my bosses, and then with the community at large, so let’s take those in order.

I reported on list that one of the themes we heard from a couple of people on the pavilion floor was that “all you guys care about anymore is AJAX.” One of the replies on-list was that the AJAX revolution is passing Java by, and that “I’d love to see those Java programmers stop disparaging Ajax and figure out how to feed into it (as google is doing.)”

Frankly, the “as Google is doing” isn’t nearly strong enough. It looks to me like the enterprise Java community is wildly behind AJAX. Consider some of the following projects, all of which have large followings:

• Google Web Kit — surely the story of JavaOne 2006, this remarkable framework allows you to code in Java and emit JavaScript and HTML. Google calls it a “Java software development framework that makes writing AJAX applications like Google Maps and Gmail easy for developers who don’t speak browser quirks as a second language.” Cooper blogged on this, and I hope to get an ONJava article from him about it as soon as possible.
• Java EE blueprints — this “best practices” project from Sun has been positively obsessed with AJAX lately, offering up a set of plug-and-play AJAX components for JSF
• Direct Web Remoting (DWR) — this framework abstracts away enough of the client-side browser muck to allow you to essentially make RPC-/RMI-like calls from your JavaScript. The new version introduces a “reverse AJAX” paradigm that allows the server to call into the browser (can you say “callbacks”? how ’bout “remote events”?). We covered this in a java.net article and hope to do more
• JSON — this format converts Java objects into string representations and has a JavaScript version, which facilitates exchange of complex objects between server-side Java and client-side script, as seen another java.net article.

There are many more examples, but suffice to say, if this is disparaging, I’m sure other programming paradigms (REST, AOP, etc.) would love to be so disparaged.

I think the mistake is thinking too much of client-side Java as threatened by AJAX. Frankly, client-side Java is a pretty small part of the Java world right now. The server-side Java guys and gals certainly don’t mind a more capable client-side approach… if anything, pushing more work out to the browser is a hugely appealing concept, if it can be made to work well and consistently, which is probably why Java developers tend to prefer these frameworks that take on the challenge of working with browser incompatibilities and hide the developer from them.

That said, taking off my editor’s hat and putting on my Java client developer’s hat, I’m still not entirely comfortable with AJAX. It’s not that I don’t like AJAX, but I don’t particularly trust it.

Analogy: the first non-fiction book I really enjoyed was Jon Freeman’s Playboy Winner’s Guide to Board Games. No, no nudie pictures — whatever the reason for the branding, this was a book with great insights into board gaming circa 1975. In its chapter on role-playing games, he reviewed “Dungeons and Dragons” and said it wasn’t really playable in its published form, and needed the players to adapt it to their style. But looking at would-be rivals, he noted that most attempts at simplification made matters worse. In the case of “Melée”, he noted that it simplified battles by relying on numerical superiority alone: a party of 21 could beat an infinite progression of 20-character parties, with no damage to itself, no awareness of effects to members, or their effects on the battle.

Here’s where this analogy is going. While client-side Java may not have the right answers to key questions, it at least knows which questions to address, and chief among these is compatibility. AJAX’s concept of compatibility is a sort of “well, all modern browsers kind of do these things more or less this way… the differences aren’t that bad, so you figure it out”. Like Melée simplifying combat by ignoring it, AJAX simplifies compatibililty by ignoring it. What AJAX gains in its key story, deployment, I think it loses in compatibility, to say nothing of lurking gotchas like accessibility. Maybe this isn’t a problem now when your AJAX app is running on the computers of you and your tech-savvy friends, but when you’re on a government contract that has to support accessibility modes that AJAX is blissfully unaware of, or when you doom level one tech support to telling Grandma how to upgrade her copy of IE for Windows 98 (”it came with the computer, I don’t know what version it is!”), I suspect we’re going to see some serious unintended consequences. Either that, or we’re in for another decade of “your browser is not compatible with this website; you must be using the latest version of IE for the latest version of Windows.”

Java deployment is a damn nightmare, no question about it, but once installed any applet, WebStart’ed app, etc. should run the same spec’ed way everywhere. That’s the point of Java. So far as I know, AJAX doesn’t have anything like the Acid test, some reference to definitively say that your app does or doesn’t work in accordance with some stated concept of how AJAX works. Instead, it all relies on a sort of trust/esteem network between app developers and browser makers. That’s powerful, but is it designed to take care of the end user? I remain unconvinced.