What is Ajax?
I’ve been getting this question quite a bit lately – especially as people find out about Foundations of Ajax. Obviously I’m not the first to talk about this but I’ve developed a bit of a stock answer so here goes. Don’t agree with something I’ve said? Let me know!
First things first, Ajax has really lost its acronym status so if you’re tossing around AJAX, you might get some funny looks. That said, you’ll see both versions depending on where you look so don’t sweat it. If anyone asks, AJAX stands for Asynchronous JavaScript and XML. The term itself comes from Jesse James Garrett and his seminal piece Ajax: A New approach to Web Applications. While the software world certainly didn’t need yet another term, Garrett needed someway to succinctly describe “Asynchronous JavaScript+CSS+DOM+XMLHttpRequest.”
Second, Ajax is not a specific thing – it represents a collection of technologies, better yet, think of it as a technique. You might argue that JavaScript and CSS and the DOM are nothing new, so what makes Ajax so special? Notice above that the ‘A’ in Ajax, stands for Asynchronous. Why is that interesting? The standard web interaction is a request/response paradigm. Remember, the Web started with a bunch of researchers sharing their reports and studies – a shopping cart was not part of the original concept. Using Ajaxian techniques, we can create a richer more dynamic user interface by allowing asynchronous communication with the server. This also means we don’t have to refresh the entire page which can significantly improve the user experience.
At this point you might be saying “so what, I’ve done this for years.” Truth be told, none of the technologies that Ajax represents are new – however, the widespread browser support is. Many people (including me) have used iframes to call the server in the background or to submit/repaint just part of the page. I’ll admit, it works fine, but truthfully it’s a hack. Today, thanks to modern browsers allow us to take advantage of a Microsoft invention – the XMLHttpRequest object (XHR for short). XHR provides a simple mechanism that allows us to call the server and tie the response to a callback function. With improved DOM support, we can take data from the server and modify just part of a page.
This means we don’t have to refresh the entire page just to fill in one or two fields. A minor thing maybe, but it really opens up some new possibilities. Like what you might ask? Well, take a look at two of my favorite examples – the browse section of Netflix and Google Maps. With Netflix, just hover over any box cover. A “tool tip” containing a significant amount of information pops up. Go ahead, view the source, the information in the bubble isn’t hiding in the page – it’s requested when you mouse over a specific movie.
What makes Google Maps so special is the scrolling. Want to see what’s off the map? Just use your mouse to drag the map. That’s it. No repaint like Mapquest. John Carroll glosses over this point in his blog on Google Maps and innovation but I really think the drag makes Google Maps so special. And it’s not rocket science! The lads at Ajaxian (Ben Galbraith and Dion Almaer) whipped out a version in less than 2 hours at a conference. Don’t believe me? Check out their piece “Ajax is rocket science”. “Ajax isn’t simple”. Enough already!
In a nutshell, Ajax is a technique that allows us to create richer web applications – applications that are often indistinguishable from their thick client cousins. It certainly won’t end world hunger or even guarantee you’ll make it home in time for dinner, but Ajax will certainly influence what we build over the next few years. We’re only just starting to explore Ajax and what it means but I’m convinced it will ultimately make our web applications more responsive and improve usability.
Hi Nate – congratulations to you and Ryan on getting the book out, I know it was a lot of hard work and you’ve done a great job.
I’ve preferred using XMLHTTP myself since 2001 or so on projects that could be limited to the browsers that supported it. I had thought many times that I might XHR-ify my iframes-based JSRS library but left it as is for those who needed that compatibility. Of course I kick myself now for not publishing any of my XMLHTTP-based remote scripting stuff at the time, but there are so many fabulous resources now that I don’t think I’d be able to offer anything new by jumping back in.
Although it’s a great improvement over really hackish methods like iframes or img/cookie, XMLHTTP was still an afterthought and I’d like to see a future where the browsers all have designed-in communication methods that give us more control for error handling, timeouts, retries, etc.
I’ve subscribed to your RSS feed now – looking forward to following along.
Thanks Brent, we appreciate that! I’m sorry your schedule didn’t allow you to continue working with us (we still snuck a few mentions in there for you!) You bring up a great point about existing iframe based Ajax techniques – should they be updated to use XHR (oh wait, you’re not a big fan of that abbreviation – I blame the guys at Ajaxian for it!). On my current application we actually have a few instances where we’ve used iframes and frankly I just can’t justify making a change at this time. Maybe someday, but how do change code that works?
Despite it’s widespread adoption, XHR is still as you say an afterthought (just look at creating an instance) and someday I too hope we have a built in way to communicate that is browser independent. I fear that a lot of shops will delay or avoid “ajaxifying” their apps due to these cross browser issues. Of course, you still need to rely on the scripting approaches like JSRS if you need to support older browsers.
Thanks for subscribing, I really appreciate another reader! I hope I write some more stuff worth commenting about…
Yep, it’s been a crazy year for me too. My company now has our wireless infrastructure and services in 400 locations across Canada and I’m hard at work scripting monitoring and configuration management on thousands of devices of various different types, all the while still building post-surgical analysis tools for the Laser eye surgery industry. Kind of all hit critical mass just before the book stuff started to heat up and something had to bend.
I agree on not fixing something that’s not broken. I’ve hardly touched the code on the http://www.blogchat.com chat application I run with Tim Aiello for nearly three years and there are still quite a few regular users.
At the time I commented that I didn’t think XHR was a common enough abbreviation to use, I hadn’t yet seen it used anywhere despite having been on top of all of the buzz. It’s become a widely accepted short form since then – looks like you were just ahead of me!
I’m starting to see some of the predictable overuse of Ajax – a user and password box with a login button and then an Ajax call that replaces the entire visible page, for instance. Some people get a new hammer and every problem looks like a nail.
That’s great to hear things are going so well for you and your company! As someone that wears classes (and has thought about surgery) do a really, really good job with those tools
We really appreciated your help – hope everything keeps ticking along for you!
Its awfully hard to justify changing code just to change code. It’d be one thing if you had to go in and make major changes that would force you to do massive retesting anyway but even then, I prefer to work in smaller steps…
Well, I think the XHR abbreviation was about the only place I’ve been ahead of you! Even then, I used it (yeah, those were my chapters – sorry about the spell checking thing!) because I’m a lazy typist. Just can’t stand typing in the whole thing all the time and I would guess we mentioned XHR dozens and dozens of times.
I’m worrying a bit about overuse myself. As you say, we’ve got a new hammer here and I think lots of folks are going to start beating on their thumbs. I’m kicking around some blog ideas revolving around that – more specifically the volume of tiny, granular requests that are going to start pooping up (can you say data transfer object?) It will be interesting to see how apps that were architected for say, 50 concurrent users will fair when those 50 users are making dozens of calls instead of just one or two.