I had a cat when I was little, called Ajax. Aha! you cry, you named him after that Greek bloke didn't you? Well actually, no. My parents named him; and they named him after a ship whose crew showed great courage and determination during World War II - the ship's name may have had the obvious origin; I don't know. The naming of my next (and current cat) fell to me. So he is called something much more mundane: Jet; because he's black.
The Ajax I'm going to talk about is actually an acronym. Yet another one. And, of course, it has to do with computers. Sorry. So, what is this AJAX of which I speak? It is the latest buzzword to hit the blogging world and it also is not related to that guy who played draughts with Achilles. Everybody seems to want a piece of the action, even though the actual acronym has only been in existence a few weeks. In its full name, it is:
- Asynchronous
- Normally, when browsing, you're used to working synchronously: You click on something; it forces a page reload; you wait. In the synchronous scenario, you and the server take turns working. In the asynchronous scenario, your browser silently talks with the server in a way that shouldn't affect the flow of what you are doing.
- Javascript
- Any programming on the client-side is best done in javascript. This language (or rather support for it) has come a long way in the past few years and, to use the appropriate marketing speak, its full potential can now be leveraged. Seriously, I love javascript: it can do a variety of really cool things and isn't too difficult to get to work.
- And
- XML
- This is of course a whole hype windbag in its own right. In the mind of the man who coined the term, the xml component of this acronym describes the data-holding powers of xml, both on the server and on the client. Javascript, for instance, can visit the DOM of xml with the same API as for html.
In the minds of most people, however, Ajax is associated with the XMLHttpRequest object in javascript, which actually powers all three aspects. It enables you to send a request to a server via http from javascript. Its calls can be either synchronous or asynchronous and it can return plaintext or preparsed xml.
So this is an exciting new technology?
Not really. It is exciting because it has had a lot of hype recently, what with Gmail, Flickr, Google Suggest and our very own e2 annotation tool. But it is not new. The potential for browsers to communicate silently with the server has existed since 1996 and the XMLHttpRequest object has existed in the main browsers since 2001. In fact, the web-based email client I use at school uses this and was developed in 2002.
The main thing we have here is a technology: in various ways, it is demonstrably possible to communicate with the server in a silent manner. Yay! And this leads us to a solution: Ajax. And now, as is the manner with all solutions, many people are desperately looking for a problem to solve. In other words, it's new, it's shiny, only the enlightened know about it, I want to be part of the in crowd. As much as the man who coined the term Ajax, Jesse James Garrett1 would like us to believe otherwise, Ajax has, in the month the term has existed, just become another (shorter) word for "Solution using XMLHttpRequest".
How does it work?
Well, assuming you know javascript, the workings are quite simple: You create an XMLHttpRequest object; you set the url, the http method and whether you want the call to be asynchronous or not; you define a return method; and send it off; voilà!.
// create a new request -- not quite as simple with Internet Explorer
xmlhttp = new XMLHttpRequest();
// open a GET request to www.server.com which is non-blocking
xmlhttp.open("GET", "www.server.com", true);
// define a function to call when the server sends stuff back
xmlhttp.onreadystatechange = function() {
if (xmlhttp.readyState==4) { // request has been completed
// do something
}
}
// send the request off to the server
xmlhttp.send(null);
What do you put instead of do something? You can either get an xml tree or, as most people do, you write the response text as a javascript object and use the eval() method to assign this object to a new variable. Something like:
// assigns whatever was encoded in the response to myvar
eval("var myvar = " + xmlhttp.responseText);
And there you have it: There is little point in actually using the XML part and it would be foolish to use something other than javascript so from all this A-J-A-X, we are just left with A: the asynchronous part.
I shall call it CLIC
There are three things wrong with this Ajax thingamajig:
- It's really only about the asynchronous part of browser scripting. Bad name.
- There are now hundreds of people trying to find a problem to associate with this solution. Bad hype.
- The hype is all around a technology and does not encompass the usability which this technology could improve. Bad philosophy.
Let us consider this last point for a minute. Up until recently, one of the major problems with web-based applications was their start-stop nature. Forever having to submit a form and wait for a new page to load. But this does not mean that such a way of doing things is bad. In fact, sometimes it is the best way of doing things. In particular, the only widget common to all browsers is the back button. Do things asynchronously and it will be broken - we lose our usual way of correcting errors. Further pitfalls include creating unusual widget behaviour and accessibility problems. In the next few months, I predict a proliferation of bewildering websites. Because they modify default behaviours and because they want to use a new technology to solve problems which do not exist; because it is all shiny and new and I want to do it too!
For the purposes of this writeup and the benefit of future generations, I have coined the term CLIC: Clientside Cleverness. This is my philosophy of where we should go. Take all the clientside web-based technologies which have matured and use the right ones at the right time to create the best possible user experience:
- Do as many clever things as possible, like form validation and such, on the clientside. Nothing worse than waiting a minute for the page to reload only to discover that you didn't fill in a mandatory field.
- Get data silently from the server, but only when absolutely necessary.
- Preserve the navigation user-elements of the web whenever possible.
- Try to make any innovations integrate into existing widgets so as not to confuse the user.
- Incorporate the remaining usability principles such as feedback and efficiency to web applications.
You'll notice that the one of the points of this philosophy is to not use this Ajax stuff - or only when it will really improve the user experience. As an example of these principles in action, let's look at how we give our credit card details to a site. It's a text box; and half the time, we get told we entered it wrong. Because we included spaces or didn't include spaces or included dashes; or not. After this Ajax noise, I'm sure some people will be silently sending credit card numbers over the network, unsecured, to have them validated by the server. Bad move! Better would be to check the form with javascript and immediately tell the user whether his credit card number is in an acceptable form or not. Even better, be informative and don't make us guess how we should enter our credit card details. Best of all: Let us enter the number any way we please, use some javascript to figure out whether you can make sense of it and only make us correct the format if really necessary.
So, if ever you feel like joining the Ajax bandwagon, think for a minute. It might take some extra coding, but there is always the CLIC way of doing things.
Sources
- http://www.adaptivepath.com/publications/essays/archives/000385.php The first article to use the term.
- http://www.quirksmode.org/blog/archives/2005/03/ajax_promise_or.html Explores whether Ajax is promising or just more hype.
- http://jibbering.com/blog/index.php?p=161 Wonders why it took so long for this technology to take off.