Bet You Didn't Know You've Been Using "Ajax" All This Time
Or, now that we have a brand name we can start arguing about the details.
Now don’t get me wrong. The web was designed for documents, not applications. So as an application platform, it has some serious limitations: you don’t have many of the UI widgets that are available to desktop applications; you have extremely limited ability to the user’s local disk; and you have potentially long pauses for the user whenever the application needs to talk to the server. Any attempt to improve on this situation is a Good Thing. All this I agree with.
Web application design has, from the beginning, been mostly about figuring out ways to overcome those limitations. As browser and client-side technology has matured, this has gotten a lot easier, especially on the widget-level end of things. You can already implement many, if not all, of the standard desktop widgets in DHTML: pulldown menus are now commonplace on websites; there’s even a solid implementation of drag and drop out there.
Give it a name
So this “Ajax” thing. Garrett pulls out a list of good practices and current technologies — XML, CSS, DOM, the usual suspects — wraps a brand name around them and declares it the next big thing.
And it probably is the next big thing, and I hope it catches on — best practices in web design run in waves and fads, so if a brand name is what it takes this time around, so much the better. But what I have a problem with is the suggestion that the goal Ajax tries to meet is a new thing.
Thickening the thin client
The primary advantage of Ajax, as Garrett describes it, is that it moves as much of the UI as possible onto the clientside. Instead of reloading the whole page every time a user does something that needs to be communicated back to the server, you use XmlHttpRequest to send just the bit of information that actually needs to be transmitted, and update only that part of the page that needs to be updated. Whenever possible, you do this asynchronously, so the user doesn’t have to wait for it (or even necessarily be aware that it’s happening.)
This is a good strategy, but other than the specific technologies described, it’s not new. And those specific technologies aren’t, strictly speaking, even necessary for this type of behavior. Years ago I was building applications that used a hidden frame as a persistent container for clientside data or session management, or an iframe as a container for a part of an application that needs more frequent updating than the rest of the page. These are primitive and limited methods, but the idea and the goal is the same.
(And I’m not saying I was anything special, or that I “invented the techniques behind ajax” or anything silly like that; these tactics were uncommon, probably because the technology was still rough enough that they were only useful in certain circumstances, but certainly not unique.)
Clientside form validation is another long-standing way to address the other end of the same problem: instead of waiting for the server to tell you something’s wrong with the form input, save the trip and check it before it gets submitted. Or: clientside in-browser WYSIWYG editors have been around for ages; at first depending on ActiveX extensions because that was all that was available, but lately using DHTML. Same deal.
So what’s the use of branding something that we were already getting around to doing anyway?
If this sort of branding leads to common, reusable implementations of these new widgets; if it leads to standards (or at least widely-agreed-upon best practices) for how best to handle communication between the browser and let’s go ahead and call it the “Ajax” layer, and between that and the server; if it turns out that it wouldn’t be better to just build this extra layer directly into the browser, or to distribute miniature desktop applications that contain both the browser and the “Ajax” layer, then it won’t be long before having to wait for any but the first page of a web app to load will be considered a sign of inferior, old-school design.
The second point may or may not happen. While it’s certainly possible for ad-hoc implementations to gather enough users to be considered standards (see RSS), there’s always someone smart who’ll come along and screw it all up by trying to improve it (cf Atom). I’m not impressed with the attempts I’ve seen so far to extend and standardize the base technologies (JSON: we’ve reinvented XML, but without attributes or namespaces, and with a whole new set of encoding issues! Now it’s perfect!) and I have a suspicion that most implementations are going to be too application-specific to get widespread use. I’m ready to be proved wrong here, though.
The third point is the big one. The distinction between a “browser” and an “application” is blurring, and getting blurrier every day. Take RSS as an example (again). First you’ve got websites using this newfangled data exchange format to aggregate data within those websites. Then you have a whole class of desktop applications popping up to read and display that data (and in many cases perform other ‘traditionally’ browser-based activities, such as posting to blogs, managing bookmarks, etc.) Then it bounces back the other way, with browsers actually integrating that desktop functionality directly into the main application. Or you’ve got applications like iTunes, which carve out little proprietary chunks of the web (loosely defined) for the music store and CDDB; or desktop widgets like Konfabulator that exist basically to bring web-based information into a non-browser-based context…
My point here is that inside the browser isn’t the only, or necessarily the best, way to think about building web applications; and that the whole idea of doing so is probably a result of the fact that we’re in the middle of a weird transition point in what an application is.
Complex web applications are inevitably going to have needs that outstrip the capabilities of the browser, and it’s already relatively simple to get all the abilities of a web browser in addition to the capabilities of the desktop. It’s also, let’s face it, a lot easier to make money selling applications than it is selling websites. (Even if 90% of the functionality of that application comes directly from the web.)
Not all web applications are going to go that route, obviously, and the browser isn’t going to go away anytime soon. (The obvious downside of that approach is that you trade in those new capabilities for the (sort of) run-anywhere nature of web apps.) So there’ll always be room for discussion of how best to improve the user experience within the browser, when it’s being used for things other than straight document delivery. Ajax is, if nothing else, a good overview of current best practices for doing so — and that alone is valuable. But I disagree that it’s a “fundamental shift in what’s possible on the web.” It’s just a new name for what we’ve been fumbling towards all along.