Enthused About: AJAX

One of the latest web development buzzwords, AJAX stands for "Asynchronous Javascript and XML". The concepts behind AJAX, though, are much bigger than a set of specific technologies. Personally, AJAX changes the way I approach web development. Here's what AJAX is all about and why I think you should know about it (and like it) too.

One of the first web tools to make use of AJAX was Google Suggest, the tool that tries to guess what you're searching for (and can sometimes crack you up) as you type. Google also makes heavy use of AJAX in its mail client, GMail, which in my experience may be the smoothest, yet most powerful web application out there right now. As I type this blog entry, it is being spelll checked (see what I did there?), which means that with every letter I type, some text is being processed for errors. All of these things are made possible, if not simply much easier, with AJAX. Here's my breakdown of AJAX in layman's terms, with some geekspeak mixed in because I won't be able to help it. Let's build the argument from the ground up, shall we?


The Web is all about clients (usually web browsers like IE, Firefox, and Chrome) that connect to servers (usually web servers that have their own domain names, like www.google.com). Since the beginning of the Web, the interaction has typically gone like this:

• Client makes request to server.
• Server retrieves content.
• Client downloads content from server.

In fact, it still goes like this, and as long as we're talking anything remotely similar to the Web as we know it, it will continue to look like this. But the problem is, when a client makes another request to the server, even for the same page, they have to wait for content to download. Browsers try to combat this with a cache, which saves a recently downloaded page for a while so that you don't have to download it again, but these days, the content on pages changes frequently - live stats, live chats, etc. Do we really want to force the browser to download a new copy of the entire page if only one line - "Jason Heyward strikes out swinging", "sup?" - is changing? What about the button you click to archive an e-mail? Is it really necessary to reload the entire Inbox just to shift the messages up one? Until AJAX came along, these types of things were actually not that easy to work with.

You could chop the webpage into pieces and have some kind of "autorefresh" for one piece. You could use a server-side technology (ASP, PHP, JSP, etc.) to run things on the server when necessary, but this makes the web pages all-the-more complicated (for one thing, they're not HTML anymore) and it increases the demands on your server. You could ask your clients to install a plugin like Flash or Java to run your content, but then you've got version, OS, and pretty big security issues. Somethin's gotta give, right?

In walks AJAX. AJAX says that if we can afford to use a light client-side technology, one that certainly isn't without its security flaws but can be fairly constrained by your browser, then we can pass off some of the "client experience" to the browser itself. The same technology could also trigger updates to the web server based on the user's actions, even very tiny actions like typing. Additionally, what if those updates could be targeted to parts of a page instead of reloading the entire page every time an update is necessary? AJAX says that if these three things are available, then we can greatly improve the interaction between users and the web content they love so much. To review, we'd like to have:

• A lightweight client-side technology for speedy response to user actions
• A way to trigger server requests based on fine-grained user actions
• A way to load portions of web content

In practice, these three desires are usually filled in by three technologies:

• Javascipt, a free-wheeling client-side programming language that can easily interact HTML and other web content
• The XMLHttpRequest object, which allows Javascript to request and receive specific pieces of text from a server
• The Document Object Model (DOM), an interface between Javascript and HTML content that allows Javascript to modify the contents of HTML tags on-the-fly

This leads to the acronym AJAX, which stands for Asynchronous Javascript and XML; but since its "creation", there has been a great deal of discussion of what AJAX actually is. Take this blog entry, for example, where the claim is made that Microsoft actually "invented" AJAX and made it available on the client side as early as 1999. I tend to agree with the author of that post, that AJAX as an idea (the first list of three technologies needed) has actually been around awhile. Now such things are finally being rolled into standards, and its up to our browsers to comply, and browser compliance is finally coming around to a bearable level too.

Like all computer-related technologies, there are interchangeable parts involved. It would be naive to think that HTML itself, Javascript, and either the DOM or XML APIs won't change over time - but the core ideas are necessary for the improved user experience that AJAX offers. Is there a reason to think that network requests will bypass the speed of local instructions? This is a different topic really, and I'll avoid the tangent, but how is any company going to deploy a usable web-based OS without relying heavily on client-side support?

So why am I so enthused about AJAX? I'm pumped because AJAX not only lets me provide better experiences to my users, but it also lets me engineer better websites. In remodeling my academic website recently, I wanted to add some structure to data such as publications. What if I have a BibTeX file with all of my citations and could just update that file and have the changes reflected on my "Publications" link? AJAX gives me the chance to do just that, which is exciting to a software engineering geek like myself. I can also use AJAX to load content dynamically, which was previously only reserved for database-driven sites. Sure, my users aren't creating the data, but I AM! Why shouldn't I be able to provide data in a very simple format and have it presented cleanly when my users want to see it? Such things just shouldn't require a database.

So the next time you're Google-ing and Google tries to out-guess you, take a second to think about the software engineer and the toolbox at his disposal that made such magic happen.