AJAX Overview
Background
To understand why AJAX is such a big, hairy deal, you need to know a little about how Web apps are built.
Client-Side
Most Web applications run partly on the user's computer. HTML and CSS are in this category. They define only static layout. To do fancier stuff, you need a client-side technology like JavaScript, Java applets or Flash. (The rest of this article will be talking about JavaScript only. Why Java applets and Flash suck are outside the scope of what I want to write about here. Maybe I'll get to that in a future article.) The advantages of running client-side applications are that they are fast (they should look and run just like an installed program) and scalable (since they don't hog the server). The disadvantages are it cannot talk to the server (intentionally due to a good security model) and you can never be sure what kind of system your users are running. They could be using any one of innumerable versions of several different browsers, or even worse, installed some sort of fly-by-night "security" software.
Server-Side Technologies
Server-side languages run on the Web server before the user ever sees one bit of HTML. Once the page appears, all of the code has finished executing. Any time you need to run more code, a new page has to be called or the current page has to reload. As you can imagine, this does not make terribly dynamic pages. Unfortunately, this is the only way to have Web pages talk to a database. Another reason this type of technology has become the main method of Web application development is that because it runs on the server, you don't have to care as much about what sort of mangled browsers your users have.
Server-Client Communication
Most Web apps use a combination of client and server technologies. Getting them to talk to one another is a collection of hacks. Usually the client passes information to the server using links with data in their query string or through HTML form posts. The server can read this data and then write new information into the Web page as JavaScript variables or form values. At its best, this process is still fairly clunky. To help deal with this, you can preload server data into JavaScript variables, but this doesn't work if the amount of data needed is too large. (Google can't really preload its entire database of Web pages into the browser. That's why when you hit the search button, you are taken to a different page.)
AJAX
Though the ability to get server data without a page reload has existed since the late 90s, I (and most of the rest of the Web developer world) did not discover it until Google Suggest Beta was released (December 2004). I quickly deconstructed what they did and built a prototype chat application using it. The term "AJAX" did not exist yet.
AJAX programming works very much like the "preload" technique mentioned above, but you can load server data into JavaScript at any time without refreshing the page. You also need to load less information because you wait for the user's input and return only what they request. I am currently writing an online adventure game using this technique. It should be ready for private beta any day now . . .
Why this is Great for Me
This has propelled JavaScript back to the forefront of Web development. Being a huge JavaScript proponent for years, it will be nice to finally kiss the "But what if they don't have JavaScript?" question good-bye. The buzz about AJAX means if you don't have JavaScript enabled, you are no longer important.
Prediction
The short-lived term "Rich Web Application" will disappear and everyone will start calling dynamic Web applications "AJAX" whether they actually use the technology or not.