So what is Ajax anyway? A not-so-easy way to add more interactivity to your web application? The essential foundation of Web 2.0? Just the latest web developer fad, following in the grand tradition of blinking text, splash pages, and rounded corners, only a lot more dynamic?
Let’s look at some common myths about Ajax and then dig up the truth.
Myth 1: AJAX is an acronym. It stands for “Asynchronous JavaScript and XML.” Capitalize all the letters or you’ll look like a dork.
Reality: According to Jesse James Garrett who coined the term, it’s not an acronym. It’s a “set of technologies being used together in a particular way” and it includes JavaScript, CSS, the DOM, and the XMLHttpRequest object. It doesn’t have to load XML; it can use JSON (JavaScript Object Notation) or other structured data formats for loading data incrementally. So if you want to seem like a geek in the know, use Ajax not AJAX when you write about it. I’ll leave to the reader whether it’s dorky to be a geek in the know.
Myth 2: Ajax will make your site more usable. Just look at how user-friendly GMail and Google Maps are.
Reality: Ajax might make your site more usable. It might make it heinously unusable too; see Yahoo’s recent redesign of their TV listings for a recent example.
Myth 3: Ajax is just window dressing–it’s only about superficial cool and special effects.
Reality: An Ajax web app, properly architected and built, can be more scalable and better-performing than a traditional cgi-architected server-heavy web application (e.g. one built with ASP.NET or Java Server Pages). For all the technical details, see IBMer Bill Higgins’ article on Ajax and REST, Part 1. Here’s the short version: web development using server-side cgi-style programs break the scalable REST architecture of the web by implementing stateless clients with stateful servers that generate one-off results that can’t be effectively cached. With Ajax, you can store state on the client and cache commonly-used server resources like reusable data and code.
Myth 4: Ajax is too difficult for the average web developer.
Reality: Ajax isn’t easy, but it’s getting easier all the time. There are a few factors contributing to the difficulty, including browser incompatibilities, inadequate tool support, and the required mindset shift from dynamic server-side page generation with a stateful server to incremental data update with client-side state management. Given Ajax’s popularity, though, tool and framework vendors and open source developers are rushing in to solve the problem. Just a few of the tools that an Ajax developer might find helpful are Google’s Web Toolkit (for Java developers), the dojo cross-browser framework, script.aculo.us for special effects, and Firebug for debugging JavaScript and monitoring XMLHttpRequest traffic.
Myth 5: Ajax breaks the browser model.
Reality: It is true that Ajax can break the back button, confuse users, and make your website completely inaccessible to people with disabilities. However, you can achieve those same things with other web development tools too: frames break the back button as does Flash in many cases. A poorly designed website doesn’t need Ajax to be completely opaque to your average user. And achieving accessibility even with straight HTML isn’t easy. This is something to be aware of and to learn about, but it’s not a problem exclusive to Ajax.
Myth 6: Ajax is a crucial part of Web 2.0.
Reality: This depends on your definition of Web 2.0. I think Web 2.0 differs from Web 1.0 most importantly on the social level, not in terms of technology. The real paradigm shift that occurred from Web 1 to Web 2 is that it’s now the two-way web, the read/write web, the social web, not the “let’s move our stores online” web. On this definition, we could do Web 2.0 entirely without Ajax. Most blogs don’t use any Ajax. If Ajax didn’t exist, Wikipedia could still work its magic. Social networks don’t need Ajax either. Flickr is notable because it provides a social platform for photos, not because it uses DHTML.
Want to know more?
My favorite Ajax-related blogs are Ajaxian and Shelley Powers’ Mad Techie Woman. Shelley’s Adding Ajax book will be published by O’Reilly shortly. I used Bill Higgins’ articles on Ajax and REST (part 1, part 2) in writing this post.
Bill is hosting an IBM developerWorks chat on moving to Ajax tomorrow (Wednesday, December 6th) at 1 pm Eastern standard time. You have to register but it’s otherwise free. I’ll be on it and I look forward to hearing more of Bill’s ideas about Ajax.
Disclaimer: IBM is a client.
4 Comments
On the subject of Ajax and accessibility, note that good work is being done in that area; see for example the “accessible DHTML” features of Firefox created as part of the Mozilla project . (IBM was mainly responsible for getting this work to its present point, and the Mozilla Foundation is funding additional work in this area, including work that will be useful for other browsers as well.)
Frank, thanks for the info about what Mozilla is doing (and what IBM has done). Great stuff.
Thanks so much for the reference to the articles and chat Anne and congratulations on your new gig! Looking forward to chatting with you today.
super stuff Anne. goes well with Cote’s agile coverage this week.
4 Trackbacks/Pingbacks
[…] Anne Zelenka, the “Red Nun” of Redmonk provides a 6-item list of myths about Ajax. Mostly I think she’s right on the mark, especially the note about Ajax making sites more usable. But I think she’s a little off track in this bit: Myth 3: Ajax is just window dressing - it’s only about superficial cool and special effects. […]
[…] If you had any doubts about whether Ajax is an acronym, be aware that it’s more and more about JSON for data exchange and not XML (which takes the X in the acronym away). Many attendees at the IBM developerWorks Moving to Ajax chat said they were using JSON for exchanging data in their Ajax apps. JSON’s cool because it maps directly into JavaScript object types, as you’d expect from the expansion of the acronym: “JavaScript Object Notation.” It doesn’t require the problematic browser-inconsistent parsing that XML demands. The only problem mentioned in the chat was that sometimes browsers choke on large amounts of JSON data. Fair enough, but shouldn’t the apps be designed in such a way that they’re only loading small amounts of data at a time? “no one paused to asked the web folk what they might actually want, and programmers’ visions yielded a replacement for CORBA and mainframe messaging rather than lightweight tools that web developers might find useful.” […]
[…] Now, that thinking is from an OO mind-set, more importantly, a static language OO mind-set. There’s a certain, as I used to call it, “good enough” mindset that we see on the public web that hedges against the danger of framework stinkatude. Here, “sloppy” (in comparison to static, OO-land) coding is the norm: HTML, dynamic languages, JSON, HTTP, and punk IT. We used to just call it “pragmatic.” […]
[…] What is really terrible is the fact that they call it an “AJAX” search. I think we can all agree that Ajax isn’t an acronym. According to Anne Zelenka, in her 6 myths on Ajax article: […]
Post a Comment