Ajax: Everyone's on the Bandwagon!

Well, it seems that everyone and their grandmother has jumped on the "Ajax" bandwagon. I see it used, and sometimes, misused, everywhere. People are applying it to many things, in many ways. This is actually a good thing, in some ways. It's great in that this sort of thing eventually advances the Web community and the technologies we use to deliver content interactively. However, Ajax should not be applied to every facet of your site, just because you get the feeling that you can come slightly closer to a desktop application. Ajax is a great approach to serving out interactive applications, but many concerns need to be addressed before seriously deploying Ajax applications on a live site.

Ajax was dubbed by the Adaptive Path Developers. An introduction to Ajax was written by Jesse James Garrett of Adaptive Path. At this point, I think it's important to point out that neither Jesse James Garrett nor Adaptive Path invented Ajax. It's just an approach to creating a different Web application. The technology has existed for quite a while longer than before the shorthand, Ajax, came to be. The possibilities of asynchronous scripting in conjunction with manipulating the DOM reveal some very amazing possibilities in producing rich interative Web applications, which do yield a particular familiarity of desktop applications. There are several situations in which you could benefit from this rich interactivity. From a marketing perspective, this can be quite the dazzle needed to gain extra business. I find that Ajax applications can vary somewhat widely, depending on their functions and how they should then be deployed. It's necessary to be aware that Ajax may not always be the best solution, and why it may not be.

Let's consider Google™'s BETA application, Google Suggest™. As we type in the search field, results are fetched by a script, which queries the database with the data provided by the last onkeyup asynchronous request, made possible through the XMLHttpRequest (or Internet Explorer ActiveX equivalent) object. The script will return the results, and JavaScript is used to manipulate the DOM, and insert the new data for the user appropriately. "Hey," you think to yourself, "why not add this so people can search my [foo] for [bar]." Depending on how novel, or useful your implementation, things may go very awry, very quickly. Now, you may be thinking, "What, exactly could go wrong?" Unfortunately, most of us don't have the resources that Google does, like numerous powerful servers and load balancing, which routes requests to less crowded servers, when others are too crowded. Consider places like Slashdot.org or the ever growing Digg.com, who have enormous user bases. All it takes is for one person to link your site, and you could potentially be flooded with more requests than you know what to do with. If that many requests all head your way at about the same time, it's pretty much a DoS (Denial of Service) for you. However, even if you're not completely flooded with packets, consider millions of visitors, all sending queries to the server for each key press. As you can imagine, this is much more taxing than a user requesting all search results at once, via a normal form submission. How lazy are we, really, that we need to know the results before pressing enter, and wating 1 to 2 seconds (haha only serious)? One of the biggest problems when implementing Ajax is that we inherently break the back button, bookmarking, and search engine indexing, to an extent. Unfortunately, a cross-browser workaround is not the easiest thing to implement. One must use iFrames (thank IE for this added difficulty) to help store previous page states, and the JavaScript code most continually check for state changes, this is known as "polling". A serious, and deep Ajax application must overcome the usability problems to remain desirable and competitive. Does all this negativity mean I'm anti-ajax?

That couldn't be farther from the truth. I, myself, have developed an Ajax-type class, which wraps most of the functionality of the XMLHttpRequest object, and enhances some other facets. I tried to focus on adding some DHTML and event registration wrapping as well. The application is still in ALPHA, and I still have a lot to learn. I think Ajax is a great tool for learning, and there are many ways you could try out Ajax on your own.

The whole idea of providing advanced, rich UIs (User Interfaces) continues to grow in popularity. Another approach, not far off from Ajax, is sometimes called Comet, at least by Alex Russell, a very knowledgeable developer on the dojo development team. This approach will sustain a single HTTP connection with a client, and push new data onto the browser, in order to allow multi-user environments thrive more seamlessly. The server needs to be equipped to handle the potential overhead of thousands+ of open sockets. Refer to the linked article for more information, as it deserves a whole post of its own.

In the end, we see that the Web and its technologies are continuing to evolve and thrive due to ideas of creative people. Although the ideas and technology to implement them may have already existed for x amount of years, only now, are many fascinating concepts of creating rich interactive applications becoming feasible and scalable, due to the increased ability to deploy the technologies across multiple browsers. While Mr. h4x0r may claim they've used Ajax and persistent HTTP connections since 2000 or whatever, such condemnation of the recent changes and increased popularity revolving around Ajax or Comet is frankly ignorant and hindering to advancement.

There's a point which Alex Russell mentioned in his article, and that is that the term serves for communication advancement. Having a simplified term wrap up complicated technology, which mainly developers understand, will greatly increase the understanding and specification about what the technology does in whole. If you've ever stepped foot into a psychology or sociology course, you may recall the Sapir-Whorf Hypothesis, which states that language precedes thought. When we don't have a word for something, we tend not to think about it. Let's try and keep an open mind, but do be careful and actually learn about the technologies we implement on our own.

Au revoir,
Curtis Dyer