Ajax is all the rage these days. The asynchronous nature of interaction with websites is all over the place, from Google Maps to Facebook to… uh… Google Maps. Faced with a Perl tutorial that I’d already attended, I decided to wade into the Ajax pool.
The problems with developing applications for the web are browsers were essentially dead for half a decade after the release of IE6, it’s hard to “subclass” HTML tags, and a couple other things that I missed. To “fix” HTML, we need to present more and more information to the users, do it more quickly than we do now, present data change better, and allow for better layer markup and behaviour.
Most of “Ajax” isn’t actually about Ajax. It’s more of a system of how users interact with data, and improving that interface. So why did it take so long for Ajax to take off? For the longest time JavaScript was a four-letter word. Browsers sucked. It was hard to make discrete requests, more than likely using <iframe> tags or cookies. From a developers’ point-of-view, all of these things were pains. Luckily in 1999 Microsoft introduced XMLHTTPRequest (XHR hereafter), which was eventually implemented in Mozilla in 2002. It allows GET and POST, and you are allowed to pass things other than XML across it. Unfortunately, the API isn’t yet standardized, so things could potentially change in the future.
During a request event there are four edge triggers that get fired, and these can be queried through the xhrObj.readyState method on an XHR object. The example given checks to see if the value is equal to 4, which is a “magic number” that doesn’t jive well with me. Can’t they come up with some named constants?
Some examples of inspection and debugging tools include Firebug, TamperData, SquareFree Shell, Drosera, Microsoft Script Editor, etc, etc, etc.
Some important XHR properties to know are setRequestHeader() (to set headers to tell the server various things about the client), abort() (to abort, duh), getResponseHeader() (to see info about what the server’s sent back), overrideMimeType() (to override the base description of what’s being sent), and onerror() (for error handling). To put it all together, we still need to get at the returned data, handle errors, put the new data in the UI, and communicate what happened to the user.
So what to send over the wire? We could use XML or various other plain-text options (JSON, HTML snippets…). Pros of XML include native parsing in browsers, XPath (mostly) works, and it’s simple to use if the data is already XML. Cons of XML include its size and the support for XSLT is spotty (but improving). Pros of JSON include it’s not XML, it’s small on the wire, and it’s really fast to parse. Its cons include the lack of any equivalent of XSLT. Pros of JavaScript include the ability to send behaviour, it’s small, and really fast to parse. Its cons include the ability to send behaviour (which is insecure) and the lack of any equivalent of XSLT.
When you’re writing Ajax-y code, you have to make sure that all of your GET requests are idempotent. Pay attention to cache control headers so you treat the server nicely. Make sure that you give the user feedback, and for God’s sake test your stuff on all the major browsers. Don’t use Ajax just because you can. Don’t build UIs that can’t operate without JavaScript, unless this is an explicit design choice.
When developing Ajax web apps, use a library. There are many excellent closed-source libraries (none of which are listed), along with many excellent open-source ones (Dojo, script.aculo.us, and YUI are three examples).
This actually answers my earlier concerns about magic numbers: libraries handle that for you.
So why Ajax? Why now? The ceiling of HTML and CSS was rapidly approaching, and browsers were stagnant. Developers hadn’t fully trawled through the available features, only “discovering” XHR recently. It also avoids plugins, and the UI improvements are useful and important to users. And why shouldn’t you use Ajax? It’s complex and costs more to develop, you have to deal with quirks in browsers and software upgrades. JavaScript isn’t a “normal” language, and the Open Web isn’t really evolving quickly enough.
It’s interesting to note that the early prominent Ajax applications were in “dead” categories: Google Maps is an excellent example of how a UI change brought users in.
There are four key things that Ajax developers should adhere to: discoverability, recoverability, context, and feedback. Discoverability refers to how the user discovers data changes and what data is available. Recoverability refers to the ability to go back, which can mean not breaking the back button. Context allows users to know where they are in the process, and feedback refers to giving the user information about what’s going on. (I think I got all that right…) A few groups have developed some UI design patterns: the Yahoo Pattern Library and ajaxpatterns.org are two.
When you’re optimizing Ajax, there are three things you need to pay attention to: bandwidth, latency, and parallel vs. serial requests. Web Inspector is a really cool way to help debug and optimize. Strategies to optimize, from easy to hard, are using the cache, making the code smaller, request fewer things, request in parallel, delay loading until you need a specific thing, and move the host closer to the client.
When using the cache, expect a 50% cache miss rate. Set Last-Modified headers to very long for static things like images and JavaScript files to take advantage of caching. You can also cache on the server-side with things like Squid, memcached, mod_cache, or database tuning.
To make code smaller, look into gzip encoding with mod_deflate. You can also strip out white space and comments for deployed code, and strip dead code out.
Alex Russell presented this tutorial, which is also available here.
