Why I do not worship at the altar of AJAX
There's a new buzzword, these last couple of years. That buzzword is "Web 2.0". Web 2.0 encompasses, oh, all sorts of vague things, like blogging, wikis and community websites, and one quite concrete one, AJAX. AJAX is simply a new name for something that has been around for a good while, client-side Javascript which calls server-side code through HTTP requests, and displays any result without going to a new page.
Now for some reason, once this was called AJAX (which stands for something rather uninteresting), people dived upon it, saying it was the future of the internet, etc, etc. Dodgy tutorials shot up, and soon thousands of people were cranking out AJAX applications.
Its uses are many and varied. The main one seems to be to build applications which interact with the server without going to a new page after every transaction, and at that it is quite good. This is not necessarily a good thing, as I'll describe shortly. There are other applications, to be sure; rather promising ones include chat applications, and simple little things like showing the correct list of states for a country once that country is selected without refreshing the whole page.
So, why are these amazing, speedy, no-new-pages applications a bad thing? Well, there are a few reasons.
First of all, they make it possible, and indeed almost inevitable, for the programmer to define their own user interface. This isn't a good thing; people are used to web pages. They think they know how web applications should work. When they click 'back' they expect to GO back, not leave the application entirely. When they click bookmark they expect to bookmark what they're looking at. When they change options, they don't expect those options to take effect until they click submit or similar; some AJAX applications, however, put them into effect as soon as they are changed. In many AJAX applications, when you click to load some data, absolutely
nothing happens until the data is loaded; no browser waiting symbols. And so on. User interfaces, in general, should stick to the
Principle of Least Surprise; that is, they should not do, where-ever possible, anything that is incongruous with what the user could reasonably expect them to do. Users have built up expectations of how internet applications work.
Compatibility, often cited as a strong point of AJAX on the basis that it, at least in theory, works on all mainstream browsers without any extra software, is actually one of its weak points. In practice, compatibility of a lot of AJAX software is often not great, especially on platforms it has not been tested on. I come across a fair few AJAX sites which won't work correctly or at all on
Safari. Now, unless I really, really need to use the site, I'm not going to bother going to Firefox. And there are few if any circumstances which would drive me to go and search for a Windows machine just to view a website. HTTP/HTML sites, by contrast, should work, to an extent, on just about anything. They may not look very nice, but they should work.
The heavy dependence on Javascript is also an issue. Perhaps because it is seen as a weird browser scripting language, many Javascript implementations leave a lot to be desire; in particular, many leak memory. If you are using a lot of Javascript, you leak a lot of memory. And some people, myself included, habitually browse the internet with Javascript disabled; saves on obnoxious sites using it.
Because of the nature of AJAX programming, it seems that programmers are often tempted to build SQL instructions on the client-side, and send them back to the server. This is almost never safe; it in effect means that the user can send whatever they like the same way. Even if the user account being used only has read access, they can bring the database to its knees with a few well-placed queries. This sort of thing is quite common;
this site has examples. Other similar issues occur, usually involving the server trusting the AJAX client too much.
Then there's performance. As already mentioned, AJAX apps often neglect to inform the user when they're downloading things. This is fine on the developer's local machine; things will load fairly instantly. From a server in a datacenter fairly close by, and using a broadband internet connection, still fine. But if you're on the other side of the world, or using a highly-contended line, or a wireless network at the edge of its capacity... You may find yourself waiting a few seconds every time you click on anything.
One of the nice things about conventional HTTP/HTML is that is degrades gracefully as usage increases beyond the limit of what the server can handle. Requests simply take a long time; this is manageable, and the user can probably still comfortably use the site. In addition, a site in this situation is to an extent self-moderating; because it's taking each user longer to load each page, there are fewer requests per user per minute, thus keeping total requests down. Now, from an AJAX perspective, when applications stop working for 10 seconds with no indication of what's going on, possibly after clicking a piece of the application's doubtless weird UI, the user is likely to feel uncomfortable, and worried. They may simply decide it's broken, and leave. And it's entirely possible that issuing of requests will not slow; from the user's perspective, they are not waiting on a page to load, so are free to do other things.
Another performance issue is request count. A conventional HTML page takes one HTTP request, plus any pictures or similar required. There is no upper limit to the number of requests an AJAX app can make, and some of them seem to have gone the way of web-apps accessing databases; the designer feels that it is entirely ok to make 10 requests at once. This puts extra load on the server, of course. This is a particularly large problem for secure applications, where all traffic is going over HTTPS. HTTPS is quite processor intensive on the server side. So any increase in requests is likely to be a problem, and, of course, HTTPS requests tend to be slower, exacerbating the issue with things taking a long time with no warning above.
Now, all that said, AJAX apps do have uses, and they are, in general at least, far better than either Java applets or horrible Flash applications from a user point of view. But I really don't see that AJAX is the miracle the internet needs.
.jpg)
