Monday, December 18, 2006

AJAX: What it is, what it isn't, and what it can do

cool stuff you can do, and stupid stuff you shouldn't

So, this word, AJAX, has been thrown around for the past couple of years, but what is it? Most people will invoke the acronym at this point, 'Asynchronous Javascript And XML', but that's not more explanatory than saying GNU's Not Unix.

Essentially, AJAX is a programming technique. It utilizes a combination of technologies - wait, scratch that. Enough explaining buzzwords with buzzwords; I might as well be telling you it's Web 2.0.

AJAX is a way of writing interface code for an application that resides on a webserver (buzzword: Web 2.0 Application), using the old standard of Javascript-controlled HTML (buzzword: DHTML) in combination with the relatively-new-but-already-ubiquitous XMLHttpRequest object. The 'Asynchrounous' part comes from the fact that, if you don't feel like making your users wait on a request to be fulfilled, you can have the XMLHttpRequest object start, and run a callback when the request either completes or fails.

AJAX is NOT, on the other hand, a magic programming language or server-side technology that allows a web application to be amazing with little work. If anything, it's HARDER to write AJAX-enabled code than a regular application.

Why use it? Glad you asked.

The major complaint people have with doing things online, for example, in checking webmail, is that it's slow and feels clunky. Programming via an AJAX method, however, allows your application to gather new data without refreshing the page - something that solves a number of asthetic and usability headaches you'd only understand if you've been writing webpages since, say, 2000.

Meanwhile, it's not explicitly mentioned anywhere in the Web 2.0 buzz, but I like to think that AJAX, as a technique, benefits from the kind of organization that comes from an object-oriented programming model. Now, while JS doesn't have an explicitly defined class structure, you can create pseudo-classes that behave, by and large, like real ones - thus obtaining all the benefits (reduced namespace impact, making for fewer script collisions and shorter variable lookup times, confined scopes, the ability to abandon the global namespace in favor of thread-safety, and the 'this.' object) and headaches (rediculous variable names like imageCache.library[25].width) that come with object orientation.

You'll note I said thread-safety. Ok, while a Javascript app will rarely bring your system to its knees or cause memory leaks (they are possible), one thing it can't avoid is race conditions (for example, if two timed bits of script want access to the same variable). A simple mutex lock is easy to implement in Javascript, and can be shared by your classes.

Still, that's MUCH later.

The next few posts here will be:
Javascript Objects: immediate and procedural, and an intro to pseudoclasses
A Simple AJAX Class
A More Complex AJAX Class
DOM Level 1 v. DOM Level 0: Quirks and Quibbles
CSS: Accessing the Sheets

No comments: