Two days ago at the OCI internal Java lunch, Mark Volkmann gave a presentation about AJAX, with the obligatory music collections browser, complete with speculative auto-completion and cascading child record table population (and a Ruby web server getting ActiveRecords from a MySQL database to boot.)
I have refrained from commenting on AJAX except for a gut reaction piece 161 days ago when Google Suggest hit the internet.
Several things happened since then: Google Maps was released and I dumped my previous internet mapping/driving directions provider within a couple of hours; And the term AJAX was coined by Jesse James Garrett to highlight the technologies that are involved, especially the XMLHttpRequest object.
Here's some of my impressions after seeing the demo in person and going through the code line by line:
It Works
The demo works. The response to key stroke events are instantaneous and screen repaint is fast. It feels like a desktop application. This may be the most important lesson I learned. With Google Maps, my reaction was different, something along the lines of "Google is a billion dollar company. Can the average IT guy handle this?" Apparently he can.
It's 99% DOM and JavaScript
Mark scrolled through the server side code really fast, saying something to the effect "This is all Ruby code. Had I written it in Java, it would be just as boring and much longer."
The focus, of course, is on client side code. It's all conventional JavaScript code. The thing to keep in mind is that there is nothing new in the JavaScript. You can add keyEvent handlers to text fields, dynamically modify the content list boxes, text areas, add and delete rows to HTML tables and change the content of table cells since forever.
The highlight of the entire presentation is the following few lines of JavaScript (pseudo)code:
// method="GET";
// url="http://localhost:8080/music/blahblah";
// asynch = true;
var xhr = new XMLHttpRequest();
xhr.onreadystatechange = function() {
if (readystate == 4) {
var domDoc = xhr.responseXML;
// use it
}
}
xhr.open(method, url, asynch);
xhr.send(null);
XML Is Non-essential
XMLHttpRequest talks with the web server at the other end of the URL through normal HTTP. It sends a request and the web server sends a response. The data communicated doesn't have to be XML. But if the data sent back from the web server happens to be XML, XMLHttpRequest turns it into a DOM. As far as the web server is concerned, this request is just like any other.
Asynchrony Is A Queue And A Thread
If I have to implement something like XMLHttpRequest in Java, I would have used a queue and a thread. The caller pushes a command object that contains the data and a pointer to the callback onto a queue and returns. A thread constantly watches the queue and acts upon each incoming command object, performs it, either in its own thread or farms it out to a worker thread, and calls the callback handler when the response arrives.
Why Is It Such A Big Deal?
Apparently you cannot do this in plain JavaScript. Client side JavaScript does not provide the classes for thread or communications programming (except for calling into Java using the applet/LiveConnect mechanism.) As soon as people realized what XMLHttpRequest can do, they jumped on it.
AJAX Is Not RESTful
In the demo, all the XMLHttpRequests are done in the REST style: each request is a GET with a URL that contains the appropriate query string, and the response would be a simple XML that contains just the data, no SOAP, no fancy schemas to wrap around anything
That's all good and wonderful. However, I have a feeling that by using AJAX techniques, you have already made your main page non-RESTful. There seems to be a bit irony here.
XMLHttpRequest Is Not Standard
As far as I can tell, XMLHttpRequest is not a standard class. It just happens to be available in both IE and Mozilla/Firefox. The way to create an instance of this class is different in each browser. Mark used a JavaScript library called Sarissa to paper over the differences.
It's kind of odd to see the web developer crowd, who usually chants "standard based development" the loudest to be so enthusiastically attracted to a proprietary class like this (and a Microsoft one at that!) I wonder if they mind that Sarissa is doing something like
var xhr = new ActiveXObject("Microsoft.XMLHTTP");
behind their back.
Come on guys, get the standardization process going. Someone write a W3C Note or something.
A Net Gain For Web Developers
From a web developers perspective, AJAX in an improvement from both the user interaction experience perspective and the network load perspective. So if you are already developing web applications by all means add the XMLHttpRequest class to your repertoire.
As your web applications become more like a traditional desktop application, the complexity will also rise. The current state of the JavaScript language dictates that the web application will always be inferior to a traditional desktop application in all respects except one—world wide deployment.
For example, Mark had a question about how to include one JavaScript file in another JavaScript file.
The Pendulum Swings Back
Alan Wang made a comment that the AJAX movement means the pendulum is swinging back to the client side after a decade of doing everything on the server.
But You Can Do This In Flash/Applets/Whatever
Yes, yes, and yes. But it doesn't matter. AJAX is the path of least resistance. For most web developers, learning a new class with a handful of methods is much easier than learning a new development/deployment environment and a new language.
What About GUI Thread Starvation?
If you are a Swing developer and have done your share of sophisticated Swing GUIs, you would cringe a little when I mention the word thread, especially ones that updates the display. Add asynchronous events into the mix and you have a recipe for months long bug fix phases of development.
It would seem to me that AJAX would push web application development closer to all of those. Maybe it will become an issue when web applications start to create thousands of little XMLHttpRequests, fire them off at the same time and watch the response come back in arbitrary order. But right now it doesn't seem to worry anybody.
Should we? I don't know. Have you experienced a website that's not just slow, but also slows down the entire browser?
What About Thread Safety and Concurrency?
If you've done threaded programming a lot, some natural questions to ask are: "Can multiple asynchronous XMLHttpRequests be outstanding at the same time? In which thread are the callback handlers run? Are there any concurrency concerns?"
I don't know the answers. Client side JavaScript is full of event handlers, most of them asynchronous, so I assume the browsers have this one figured out.
Is It Still A Web Application?
Of course it is. It runs in the browser. But!
It will be harder to develop, harder to design, and harder to fit the application within the web browsing experience. The Back button will become less intuitive. The Stop button will cease to be an indicator of the presence of any web activity. The Refresh button will probably be disastrous if clicked.
In essence, you are developing a web application in name only. The expectations/experience impedance will be the down fall of AJAX.
From a development perspective, especially for new projects where I have a choice between Web vs. Swing (or some other GUI technology) the line needs to be drawn differently: Instead of dividing them up like this
Web apps, including traditional (request/response) and AJAX
GUI apps
I would divide them differently now
Request/response web apps
Rich apps, including AJAX web apps and GUI apps
What Else Is Already In The Browser That We Are Not Using?
If XMLHttpRequest has been in the browsers for a long time without us seriously using it, a natural question to ask is "What else is in the browser that we are not using?"
If we are happily using a proprietary class in IE (that is subsequently made available in other browsers), can we do the same for some of the Mozilla/Firefox features? After all, it's much easier to take a feature that already works in Mozilla/Firefox and make it available to IE (as an ActiveX object, for example) then going the other way around.
Previous Topic
