SXSW Notes: Ajax — What Do I Need to Know?

Loose notes from SXSW 2006 session: Ajax — What Do I Need to Know?

People tend to think of Ajax as a magic bullet … but it’s a bullet it’s really easy to shoot yourself in the foot with. New opportunities in web-based UI, but the field is riddled with gotchas.

David Humphries
Jesse James Garrett – Coined the term Ajax, cofounder of Adaptive Path
Dylan Schiemannn – Co-writer of the Dojo library
Dori Smith – Author of “JavaScript for the World Wide Web”

XMLHttpRequest is a misnomer – doesn’t have to be XML – can be text, javascript, etc. Named by MS a few years ago.

What happens when you press the back button? Back a page? Back a step in the UI? You don’t want to go back to data that’s out of date. Must define carefully what the interaction is.

Cross-domain problems have always been an issue, but are an even bigger issue with Ajax.

JSON-RPC provides a callback function – implicit trust between you and the content provider.

Progress indicators – Flash can say “10% done” but there’s no equivalent in XMLHttpRequest.

Race conditions – trying to load data before data is returned, etc. Very common in Ajax dev.

No drawing objects – we need a declarative vector lookup. SVG and Canvas are coming but not all the way there.

Getting started: Determine requirements, find a good toolkit or existing code. Dojo, MochiKit, Prototoype are all open source.

Hand-making everything is OK for one-off implementations, but doesn’t scale. There’s a lot of re-invention of the wheel out there. Use a toolkit.


DHTML Universe:






Objections to Ajax: Accessibility and Usability. Will people with no JavaScript get nothing at all? What about people who have turned it off? And people with older browsers….

User expectations. As web apps come into public view, People expect the back button to work. Code is out there to make the back button work in various ways – use it.

Typical Ajax app doesn’t include a savable URL (similar to the old frames problem).

Will the API survive the years? Eight years ago there were a bunch of cool JavaScript APIs to choose from and plug in. But what happens when you build on top of a toolkit and then the toolkit goes away? Open source should do a lot to mitigate this problem, give the toolkits staying power. People have learned how to do large-scale open source projects with legs.

Cross-version support — thorough testing even more important. Yahoo is being very transparent about their browser support/recommendations.

If you’re coming from the server-side dev side of things and think you can learn just enough JavaScript to create Ajax: “Writing JavaScript that looks just like perl (or python, or java, or … ) is not the best use of JavaScript — a full-fledged, very powerful language, not to be trivialized.

Navigation issues: Slow response times (e.g. in dynamically updated picklists) can cause all kinds of interface issues.

Search-engine friendliness: How much text do Ajax applications give to Google, or not?

Decoupling user interaction from server communication via XMLHttpRequest is the key, and will have a huge impact on the public face of the web, but presents dozens of challenges to be worked out.

Security: Toolkit makers are at the mercy of browser vendors. But that doesn’t mean we do things stupidly. But it is a vast topic. There are encryption APIs, sanitizors, etc.

One Reply to “SXSW Notes: Ajax — What Do I Need to Know?”

  1. Pingback: credit check free

Leave a Reply

Your email address will not be published. Required fields are marked *