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.
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
- Javascipt, a free-wheeling client-side programming language that can easily interact HTML and other web content
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.