« Building Scalable Internet Architectures | Main | Improving the Blog Authoring Experience with MovableType 4 »
July 24, 2007
Alex Russell: Learning Ajax
Getting ready to listen to Alex Russell give a tutorial entitled "Learning Ajax" (slides) at OSCON 2007. Alex is the lead developer of the Dojo toolkit.
[I've been doing/using Ajax for some time, but never had any kind of training so am looking forward to a good overview and hopefully will pick up some new things.]
OK, we're underway.
The talk is about applications, not pages or sites. Web applications aren't necessarily better, the technology isn't actually that great for building applications compared to OS-built programs. But there are some tools to make today's web much better.
For a period of time a few years ago the web kind of stalled, HTML and CSS got hacked up over and over to try to make things better but nothing new. This period allowed other browsers to catch up to IE which had all kinds of development dumped into it. [Side note: IE team was dispanded after IE 6, evidence that the browser had stalled].
The fix to the stagnated browser was to have something that could enable incremental data change, let users explore data more easily, present data change better and provide better layer markup and behavior.
When Ajax was first coined it was something different from what we know Ajax as today. Ajax was originally all about improving the user experience and interaction design, not about the technology itself. Alex still likes this view and prefers to spend trainings like this talking about the less technical pieces and how the UI design happens.
Ajax was made possible technically with XMLHTTPRequest, introduced by Microsoft in 1999. Mozilla implemented in 2002. Allowed us to avoid the "click of death" using both GET and POST. There is a same-origin policy (can't go to another site to make requests) and not a standardized API, but XHR is the best thing that has happened to the web since the late 90s. XHR request was designed to get XML, but quickly figured out that the requests could be anything text that can be pulled off the wire.
[looking at a getXmlHttp() function and using it to grab a URL]
[Alex pauses and tells everyone to install Firebug before we continue (shows off the Net tab to look at all network traffic from the web page) - IE 7 has something similar in Microsoft Script Editor which came with Office 2000/2003 - Drosera is good for Safari, available in nightly builds as part of the webkit]
Alex plugs virtualization software (Parallels/VMWare/VirtualPC) as a must for a web developer so you can quickly get at pages through different browsers.
Extra XHR methods to know about:
setRequestHeader()
abort()
getResponseHeader()
overrideMimeType()
onerror()
When using Ajax techniques you can get data in a few formats, XML, JSON, JavaScript, or plain text. XML is large and you have to work around encoding (make sure you send the mimetype "text/xml"). JSON is much smaller on the wire and fast to parse, but transformation is slow and there is no XSLT. JavaScript is handy, small on the wire, and can be easily executed using eval(). Sending JavaScript can be dangerous.
[Alex digs into an example of using XML and XSLT]
Ajax Dos:
- Pay attention to cache control headers
- Give users feedback (any request longer than a second should have a progress bar or some indicator)
- Make sure you test on all browsers.
Ajax Don'ts:
- Just use Ajax because you can
- Build UIs that can't operate without JavaScript (unless a design choice)
- Assume that you know the pitfalls because you attended the tutorial
- Synchronous requests "hang" the UI
- IE 6 has a memory leak
- 2 concurrent connections, no more
- POST and GET most reliable today
- Can't "talk" across domains
- No file upload (can do something that feels similar with an iframe)
- Return order not guaranteed in async mode
Alex spends a little time looking through the currently available Ajax toolkits. Bottom line is at this point there's no reason to write something new.
Ajax makes actions atomic.
Four important interaction design principles (from Jeff Veen):
- Discoverability - how hard to I have to work to find out what the system can do for me
- Recoverability - knowing that the application won't punish me for trying to go down a path (must be present to make discoverability work)
- Context - how easy is it to put the data into a context, get from here to there
- Feedback - what is the system doing, don't leave me in the dark when the system is working for me
[Alex gives a demo of live search with a built-in keystroke delay detecter to make sure it's not searching on every change, but is smart to only do the search when the user pauses]
...in progress...
Posted by mike at July 24, 2007 8:26 AM