|
The Year of AJAX
by Kito D. Mann
March 16, 2006
If your head wasn't in the sand during 2005, you've probably heard of AJAX (Asynchronous JavaScript and XML). Just in case you're wiping the sand out of your hair right now, here's a brief overview. AJAX is a rebranding of technologies introduced in Microsoft Internet Explorer (IE) several years ago. These technologies, branded by Microsoft as Dynamic HTML (DHTML) include HTML, an implementation of Cascading Style Sheets (CSS), plus the ability to manipulate a page with JavaScript through the browser's Document Object Model (DOM).
IE 5.0 quietly introduced something quite innovative (if proprietary): an ActiveX object called XmlHttpRequest. This object allows developers to write JavaScript code that communicates asynchronously back to the server, retrieves a response, and then dynamically updates the display without requiring a full-page refresh. Since updating part of a page is faster than updating all of it, applications appear much more responsive. (Note that you can dynamically manipulate the page with JavaScript even if you don't talk to the server first.) With AJAX, Web applications can behave more like their desktop counterparts using a Web browser (no special software or plug-ins are required).
Why is DHTML—I mean, AJAX—so popular now? There are a plethora of different opinions on this topic, but I think the answer is pretty simple. First of all, people are sick of the limitations of browser-based user interfaces, especially for Intranet applications. At first, it was cool and hip to use new technologies and avoid deployment nightmares, but people have finally realized that it might be nice to have more than a few basic widgets to work with. Second, developers love Firefox. It's the first version of Mozilla to truly take off, so much so that Microsoft is releasing an extra update to IE just to compete. However, Mozilla has supported the XmlHttpRequest object since 1.0. In other words, AJAX is fully supported by all browsers (Apple Safari and Opera added support recently).
The immense interest in AJAX, since it was originally coined by Jesse James Garrett of Adaptive Path in February 2005, makes it probably the number one buzzword of 2005. So far this year we've seen several AJAX books, AJAX Web sites (I highly recommend www.ajaxian.com , run by Ben Galbraith and Dion Alamer, coauthors of the forthcoming book Pragmatic Ajax [Pragmatic Bookshelf, 2006]), and of course an endless supply of AJAX frameworks.
Why do we need AJAX frameworks? As it turns out, once everyone started writing a bunch of JavaScript again, they remembered how much of a pain it can be, especially since there aren't too many good tools on the market. While AJAX is a powerful technology, it's pretty low level, and anything that's low level could use a few layers of abstraction (even Microsoft has a framework called ASP.Net Atlas).
What does this have to do with Java? A lot, because people use Java to build quite a few Web applications, and, as with any new (or newly rediscovered) technology, the industry is still trying to figure out how to use it best. People are still figuring out how to handle accessibility and how to avoid excessive bandwidth usage. Some people think that if you're using AJAX, you no longer need a Java Web application framework (theoretically, the browser can talk directly to Web services!). Others have tried building a lot of custom AJAX code only to quickly realize why they haven't written any JavaScript in a long time.
The Web application framework market has been quick to respond; you can now use AJAX with JavaServer Faces (JSF), Struts, WebWork, Tapestry, and so on. These frameworks handle things in different ways, but the key point is that it's possible to leverage what you already know. There's no need to reinvent the wheel. And unless you're anxious to manage all of the complexities of the browser DOM, JavaScript, and CSS, you probably shouldn't.
The bottom line is that AJAX is here to stay, and it's great to see that the Web has quickly realized a powerful, (sometimes) backwards-compatible evolutionary path. Fortunately, the Java ecosystem is dynamic enough to rapidly support new technologies, and you can use your existing Web framework with different AJAX frameworks.
Component-based Web frameworks such as JSF give you the best of both worlds: components that have both server-side and client-side representations, which means that developers are shielded from the complexities of AJAX and use the same event-oriented programming model whether the components are displaying AJAX code; WML; XUL; or plain vanilla HTML.
AJAX is a powerful way to use a set of ubiquitous technologies, and it's here to stay (although, I'm not convinced the buzzword will be immortal). For Java developers, architects, and managers, the key is to make the best decision for the project at hand. More often than not doing so means using frameworks, either on the client, the server, or, better yet, both. The most important rule, however, is to remember that any technology should be used only where appropriate: every single Web application doesn't need to be "ajaxified," and those that can benefit from AJAX may be fine with just a few "ajaxian" features.
About the Author
Kito D. Mann is editor-in-chief of JSF Central, principal consultant at Virtua Inc., and author of JavaServer Faces in Action (Manning, 2005).
Back to top
|