The AJAX Melee

by Chris Adamson

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.


2006-05-22 13:27:45
We just completed building an Ajax game powered by Java on the backend.
2006-05-23 13:36:24
I think it will be an interesting challenge to see who offers better functionality to web app developers (the client-side AJAX library vendors & frameworks or the server-side Java-based frameworks like Google's). I couldn't imagine people completely abandoning desktop-based or Web-Started apps, but I can see AJAX-based offerings seriously helping people who develop many company-internal web-based applications.
2006-05-25 09:19:59
The idea of AJAX is great but what it lacks is a true standard that nails what it to the floor so to speak. What may work on one browser will just fallover on another...and so on. I like some of the AJAX stuff but what it boils down to is that AJAX is just trying to work round the problems of HTTP request/response and make it feel more like a continuous connection

What I would like to see is some new standards for browsers to implement that does away with the FORM post/get methods etc and brings in a whole new set of tags for handling html events between the client/server

Its way overdue!

2006-05-26 08:49:37
I got my first grey hairs writing my first dhtml single page web application that had to look "just like this bespoke Visual Basic application" and run on Netscape 4 and IE 4+. I was really pleased that I wrote a data grid on the page that was a sort of Excel workalike - using Netscape layers and IE DIVs rather than inputs. We even got hold of a beta release of the first VMWare server to host our own quality assurance lab with every version of those browsers that we could find.

Immediately after that project I found a startup on the web that had written a spreadsheet in dhtml than ran in all browsers and worked beautifully. Gee I was impressed at their cross browser javascript libraries - having cobbled together my own crude attempts. That was the year 2001.

So the whole "cannot trust the browser" stuff in the article seems a bit Chicken Little to me. Every new developer trend brings both opportunities and risks. J2EE is great. Have you ever had to work on a big j2ee app where the developers didn't get it and wrote their own poor MVC framework? Nasty. Ajax is great. Did you hear the one about the developers that wrote their own javascript library for Ajax and it didn't work in any browser that they did not have installed at their offices? Same thing. Fools rush in with their own code. Wise men find a stable framework or library (commercial if you must - opensource for preference) and code to that. Then they focus on the value added in their application rather than on re-inventing their own version of the wheel.

At the end of the day for most folks if your competition has a rich Ajax web app that work in 9/10 browser and you have a basic web app that work in 10/10 you are going to go out of business. (Clearly government projects don't have any competition so they don't have any pressure to have a rich app.) So to me Ajax is here to stay. What I have yet to see is any articles about how to take the approach of "Ajax when we know the browser is one we tested against, else don't do Ajax but old school html" without lots of duplicated code. That is to say "how do I write a site that runs as Ajax in compatible browsers and plain html where it is not - without me having to maintain two versions of my site". That would be a killer framework...

2006-06-05 05:53:34
AJAX is interesting framework that most of our current application can leverage it. In the contrary framework/technology will come at its own cost. AJAX is very much vulnerable to errors if the framework is used for
1. High visibility sites
2. Cross Browser and different version compatibility.

To mitigate the above pitfalls, I believe that developer need to use both normal/existing flow and also enabled with AJAX. If AJAX is not supported then it would take normal approach.

strass Madrid
2007-01-25 03:01:59
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 do not agree. Go to