30 AJAX: what is it good for

Chris McEvoy did a spoof entitled Why Ajax Sucks (Most of the Time), based off a well known Alertbox article — Why Frames Suck (Most of the Time), aimed at frames — written by usability “guru” Jakob Nielsen. Chris redirected his piece towards AJAX with only minor modifications.

Unsuprisingly, AJAX came out of the clinch looking rather bad. This is one of the first big slashbacks at the AJAX hype of late, and rather unique in its negative approach. But it was time the downsides to this new technology got some exposure as well.

1. The frame analogy

Hey, said McEvoy, remember frames? That’s AJAX for you, right there. He who uses AJAX on regular websites gets no pretty printing, no back browser button, no search engine friendliness, no accessibility for disabled users, and no bookmarks. The article describes all of these problems in detail, so I won’t repeat them here.

The frame analogy is dead on and manages to summarize the basics of “what’s wrong with AJAX” better than anything I’ve seen so far. The original article was written by Jakob Nielsen back in 1996 and proven right by the passage of time. Today, use of frames on the Web at large is restricted to a handful of sites which would be best described as “web applications”: webmail interfaces, for the most part, and sites which need advanced interaction and can afford to miss part of the regular Web functionality.

Of course, like any analogy, this one has its weak points. AJAX is not identical to frames. It was built (no matter how crudely) on top of standards which were designed to be accessible and degrade nicely, such as XHTML and CSS. Some of the problems described by McEvoy can be improved upon if the developers are willing to take the time to do it.

2. The problems with AJAX

2.1. Accesibility and breaking off from the classical Web

Printing can be improved through the use of alternate styling sheets. Accesibility and search engine friendliness can be achieved with alternative implementations (ie. non-AJAX). Probably bookmarking can be fixed as well, if developers manage to use URL characteristics (directory names, GET parameters) to describe unique states of the AJAX interface.

But most developers aren’t willing to take the time for this. Making AJAX play nice within the classical Web paradigms involves rather elaborate efforts which can well double the amount put into developing the main product, and it often requires alternate versions to be made available. While part of the developing teams will have the resources and expertise required to do this, most of them won’t.

Problem 1: AJAX attempts to become the bastard child of the Web, breaking off ties with its ancestry.

2.2. The hype, and using AJAX in the wrong places

The problem is further composed by the insane hype. Seems like only a month ago everything was quiet, whereas today it’s AJAX everywhere: “classes” written in all the languages that can handle OOP to any degree; we have dedicated websites, articles, discussions, the works. Naturally, managers and executives are all excited and gushing “gotta have AJAX”! Many of them seem to ignore one of the most sound advices when dealing with brand new technology: if you’re going to use it for anything crucial, let the hype pass, and then examine the survivors and the aftermath.

The statistics are very seductive as well. Market droids will look at their corporate website stats and see that 98% of visitors have JavaScript enabled, and that 90% to 95% use an AJAX capable browser. It’s going to look like very nice odds in favor of it, the kind of odds that Flash and Java applets never had. Hey, let’s add some squiggly things that move and jump around, they’ll demand.

Problem 2: Letting the dark forces of marketing and hype push the use of AJAX everywhere.

2.3. Bad implementations

Let’s back down from the excitement and think about it for a moment. Who are the people implementing AJAX? Most of them aren’t experienced GUI designers, and yet that’s exactly what AJAX does, it implements interfaces. Having amateurs deal with this leads to all kinds of pitfalls.

No, experience with website layouts or (for God’s sake) desktop publishing does not qualify you for GUI design. Desktop applications stand in a class of their own, have their own functional paradigms and accessibility theory. One single example: on the Web, it’s considered acceptable to have a page respond (ie. load) within 10 seconds. On the desktop, the response time must be 1/10th of a second.

Furthermore, let’s not forget that AJAX itself is a bad implementation. It is no more than a hack, a bastardization of standards and technologies that were not meant for this. While HTTP itself is a very versatile protocol which can be used for a lot more than it’s being currently used for on the Web, the combination of XHTML, CSS2 and JavaScript with the remote procedure call slapped on top isn’t exactly a rock solid GUI API.

From this stem a whole load of other issues, of which bad UI design is the least; just think of having to deal with latency, concurrent requests, locking, security, race conditions. What AJAX lacks is a proven framework. They will come, in time, but right now it’s a bloody hackfest going on.

Problem 3: AJAX attempts to bring desktop interfaces to a patchy platform not meant for them, and this means a lot of pioneering and experimentation.

3. The wake-up call

3.1. Online commerce is still expectative

Let’s cast our eyes towards where the money is. Have you seen any major shopping sites jump on the AJAX bandwagon? Do you think they dare lose even 1% of their visitors just for the sake of new technology? Is a more responsive UI really worth it, in an environment where being able to cater to as many visitors as possible, and to process their orders and shopping experience securely and reliably, is paramount?

And if some of them do start using it, will they make a full conversion or just small tentative use of it? Want to bet that the cunning foxes behind the successful sites will wait to see what comes out of this before they commit? After all, they see new technology come and go all the time. They didn’t survive so far by slapping each new discovery on their sites.

3.2. AJAX belongs in Web applications, not on the Web at large

Having spent the better part of the last five years developing a Web application, I tend to see McEvoy’s point. To certain extent, our team made use of many DHTML tricks, even some that would be considered very close to AJAX today, if not really AJAX. (It’s actually interesting to see that eventually everything converges to the same solutions, at least in principle if not in implementation.) And before you have to ask, yes, we use frames too.

Getting back to the comparison with the “classical Web”, I can see we’ve been through all the issues presented in the article. Our application today lives in a browser window that’s been stripped of most anything except the main render area. We’ve implemented our own navigation and bookmarking system, complete with our own version of the back/forward buttons. We control printing jealously, by converting the interface output to formats that make good printing material. We don’t care about search engine bots, and although I may personally feel like an asshole about it, we don’t care about disabled users either.

Quite a far cry from the run of the mill website you see every day, wouldn’t you say? These are all things that came out of necessity, the necessity of having a highly interactive, thoroughly controlled interface. But that’s exactly it: the Web is not like this. This kind of Web applications are not the Web, they are particular implementations using Web technology. These exceptions reaffirm the rules of the Web.

3.3. Leave the Web alone, build something new

They said all these things about Flash and applets before. And so far all these things have been proven right. Flash, Java applets, SVG, VML, frames, the canvas, they have all been eventually relegated to a niche. The vast majority of the Web still stands as text and images, with a touch of DHTML added tastefully and moderately in some places.

My objection to all these alternative technologies is not personal. We need advanced interactivity over the Internet. We just don’t have to push it down the throat of the Web.

The Web we know is a solid, proven environment. We’ve all come to expect it to behave in a certain way. The model it has been built on is good, it’s simple, widely accepted, and it works well. Why break it with a radical new model? Of course there are improvements that can be made in many areas (online shopping, privacy and identity, security, advertising). But a fundamental change of its very core is not it.

Let me ask you something: why are all these alternative, highly interactive, technologies still clinging to the Web? To some degree, it’s understandable; they hope to piggyback onto the Web’s popularity and acceptance. But from a tehnological point of view the dependence stops making sense. Like it or not, the Web is limited, not in the technical possibilities, but in the model it has created in the minds of its users.

Why not build a completely new environment, specifically for the use of advanced interactivity, one with its own usage model? Back in the 90’s the Web coexisted with Archie, a completely different environment, based on distributed menus, and with Usenet, with its well known ups and downs. Email is another environment of its own (albeit slowly dying, by the looks of it). Instant messaging and conferencing (be it text, voice or video) has its own. Multimedia distribution, for entertainment purposes, in the form of video and audio streams, is starting to emerge with a model of its own. So it’s not only possible, it’s downright imperative.

Granted, it will take a lot of investment, risks, and a lot of heckling from the competition. If whoever implements it tries to control it too badly, consumers will resist it. It will take just the right conditions to make this come true. But, if anything, this new model is the fabled Web 2.0, not something they slapped over our good old Web.