Pascal Kriete

Ajax Tutorial: The Basics

A while ago, I made the offer to write up a tutorial on anything you want to see. Most of the requests were asking for ajax tutorials.  It’s surprising, since there are already quite a few of them out there.  Michael Wales made one quite recently, and Derek Allard even has a screencast covering it.  That leads me to believe that people are having trouble understanding the fundamentals.  So I’m going to make a series of them, from theory to a full CI implementation.

What is ajax?

Ajax is an abbreviation for asynchronous JavaScript and XML.  It’s a way of making a hidden asynchronous request.  Asynchronous?  Yes, a request that is run in parallel to other actions.  What it means is that when you initiate a request, your script continues to run and does not wait for the request to finish.  It’s also hidden so it doesn’t affect the page you’re viewing.  It’s all done in the background.

An early version of asynch requests was the iframe.  When you click on a link in an iframe it will asynchronously load that link, the page you’re viewing won’t change.  The only difference is that you can see the loading process, it isn’t hidden.

Using javascript to make asynchronous requests has actually been possible since Microsoft introduced the XMLHttpRequest object in 2002, so it isn’t the new technology that it’s sometimes hyped up to be.  It caught the public’s eye when Google launched gmail in 2004, and really made a breakthrough in 2006, when the W3C made it official.

Graceful what?

In the current buzzword market two things that always come along with ajax are graceful degradation and progressive enhancement.  That sure sound fancy, but what is it?  They really aren’t related to ajax as much as they are to javascript in general.  Ideally one leads to the other.  You first build your application on a pure server side layer.  No javascript at all.  Once you’re done you drop a javascript layer on top to streamline the user experience.  That is known as progressive enhancement.  Now, when a user comes to your application with javascript turned off, they can still use it without any fancy effects.  Your application degraded gracefully (as opposed to turning into a shambolic mess).

Benefits and Drawbacks

There are obvious benefits to calling a server page in the background.  You can call a page that performs an action, like update your database.  Normally the user just sees a message to tell them it was done.  That’s really all they care about, one word: “Done”.  On a fast connection it really makes no difference, but if you’ve had the pleasure of using dial-up recently (and yes, people still do), not having to wait for all those images to load again is a real boon.

There are downsides though.  Since you’re not reloading the page, the browser doesn’t know you’ve actually completed some sort of process, so the back button doesn’t work as expected.  Most of the solutions to this use the url hash (the stuff after #), but if you send that link to someone who has javascript disabled, it won’t work for them.  Also, search engines don’t know javascript, so if your website doesn’t degrade that content will never be indexed.

Implementation

In the next part I’ll talk about the javascript implementation, how newfangled libraries can help you, and show you my preferred way of messing around with it.

Notes

- Google reader still picks up the feed for my old blog so you need the complete url if you want to subscribe (all the cool kids do it).
- A lot of this post is my take on the wikipedia entry (just covering my back ).