Introductory AJAX Topics
.After collaborating with me on an AJAX enhancement to our web application, my co-worker Ryan today asked me to give our engineering group an introduction to AJAX techniques. That seems like an interesting idea, so I’m going to sketch out the kind of thing such an introduction might cover.
Web/HTTP Basics
The main point here is that the HyperText Transfer Protocol is page-based. Individual resources such as images (or iframe contents) can be altered, but the protocol itself does not support the idea of updating content without a reload of the page and all of its resources. Any transaction involving sending info (including the basic case of making a request) from the client to the server results in a reload of an entire page (either a new page or the same page).
The protocol itself does not support the concept of page fragment or micro-content updates.
Document Manipulation
JavaScript is the client-side scripting language of the Web. Its purpose is to allow web developers to script behavior and interactivity on web pages. This includes the ability to rewrite some or all of the page. The old (and deprecated!) way of doing this was to use document.write(), as in:
<p>Some text. <script type="text/javascript">if (some condition) {document.write("something that changes on button press/timeout");}</script>. Some more text.</p>
Modern browsers deal with this much more cleanly, and are furthermore able to access the document using the Document Object Model, which allows for clean separation of behavior from content and appearance. The same effect as above would be achieved with the JavaScript tucked away in a separate file, and the same paragraph woud look like this—the key point being the id attribute that makes the section to be altered easy for the script to hook onto:
<p>Some text. <span id="theChangingTextSection">text to be changed</span>. Some more text.</p>
Regardless of technique, however, the key is that JavaScript can alter sections of a page, and since this is happening client-side, there’s no need for a page reload.
XMLHttpRequest
All major browser also support, via JavaScript, the XMLHttpRequest function (effectively, although for IE this involves using an ActiveX call). This function has the client browser request a new document from the server in the background—the document is for use by the script, and not necessarily for display to the user. The expectation here is that the document returned will be XML, hence the name of the function, but in fact any HTTP-available resource can be returned this way.
Document Manipulation + XMLHttpRequest = AJAX
Asynchronous JavaScript And XML. “Asynchronous” because it’s not tied to page (re)loads. JavaScript because that’s what manipulates the client-side DOM. XML because that’s the expectation for how the content delivered asynchronously will be formatted.
Simple example: Google Suggest.
Google Suggest would be unfeasible without asynchronicity. Its functionality is simple: when you type, suggest a bunch of things that begin with those letter that other people have searched for (and show how many results each would return). With AJAX, the client-side script watches the keystrokes in the form input, and asynchronously background-requests from the database backend those things that match the keystrokes.
Without AJAX, the two alternatives are to either do a full page reload after every keystroke, which would be a terrible user experience, or to load the results for all past Google queries into the page…
XMLHttpRequest Alternatives
There are other ways (despite what I said in my last paragraph) to get data asynchronously.
The first is to use iframes. These are frames within a page that contain other pages. With this model (used by Google Maps), the required data is loaded into a hidden iframe. This iframe is controlled by JavaScript, which tells it what to load and then parses the data from that load into some form that is then reflected on the parent page.
The second is to use JavaScript to add a new script tag, with a source URL, to the head element of the page. This JavaScript is then evaluated, and becomes available to the JavaScript already on the page. The JavaScript can include functions that return values that are used to update the page. The sfmagic.org FAQ uses a variant of this technique, where the script element isn’t added dynamically, but does return a piece of JavaScript that’s actually a server-side script returning attendance statistics.
Modern DOM + Asynchronicity = Rich Web Applications
These techniques combined allow for a far better user experience, and application possibilities that did not exist before are being made into applications.
Security
Since AJAX requests are hidden from the user, there are many potential security holes here. In an attempt to prevent these from getting completely out of hand, browser makers have placed significant limits on these techniques, and the primary one is that JavaScript on a page cannot use XMLHttpRequest or iframe to access content from a domain other than the one the page is on.
The script element is not subject to such a restriction, although for a variety of reasons this is trickier to exploit.
Progressive Enhancement
As with any cool new thing, people get carried away and often forget the basics. The right way to approach web applications is via “progressive enhancement”, where the app is still usable without all the fancy AJAX, but simply gets better and better when it’s available. As Jeremy Keith (author of DOM Scripting) puts it:
Plan for Ajax from the start.
Implement Ajax at the end.
Client-Side is User-Side
Lastly, I of course feel compelled to also emphasize that both DOM manipulation and asynchronicity allow users to do plenty of cool things too, running their own enhancements on pages and, with Greasemonkey, effectively adding significant improvements previously only possible with access to a web application’s server. For reference:
Enhanced Pricelist Bookmarklet
Zipcar Greasemonkey Script