Ajax is Not Really What You Think It Is

A big trend in project and job postings lately is experience with Ajax (not AJAX – it is not an acronym). Yes, I know that it’s the big thing right now, but I would guess that 99% of the time, the people asking for it really have no idea what they are asking for, and are really using the incorrect term. My goal here is to explain the differences between what Ajax really is and what most people are interpreting it to mean. In addition, I will explain why Ajax is not really as vital as some people think it is and when you should or (more importantly) shouldn't use it.

Ajax is Not a Technology

The actual technique of Ajax requires the use of all of the following (pulled from the Wikipedia article on Ajax):

• XHTML and CSS for presentation
• The Document Object Model for dynamic display of and interaction with data
• XML and XSLT for the interchange, and manipulation and display, of data, respectively
• The XMLHttpRequest object for asynchronous communication
• JavaScript to bring these technologies together (this point is slightly inaccurate, because any available client side scripting that can make server calls can be used; JavaScript is just the most prevalent)

I have seen very few people actually using Ajax on their sites when they say that they are. Most of the time, it is purely using JavaScript to make things change on the page, like slideshows. A slideshow definitely can use Ajax to render, but only if it is retrieving and changing content via asynchronous calls to the server. The “Ajax functionality” I typically see loads all content right away and then just uses JavaScript to change it. This is not Ajax, this is just simple dynamic HTML (DHTML, which is an acronym), which combines JavaScript with HTML. Ajax is a more advanced subset of DHTML, true, but most people are really just looking for basic DHTML, not the advanced functionality you get with Ajax. The key aspect of Ajax is sending and retrieving data from the server and using that data to change the content on the page.

Another key point about this is that I have met very few developers (and almost no designers/front-end coders) that actually know how to implement Ajax and have any experience in doing so. Writing real code for Ajax is incredibly complex. For developers, most of the time, we are prone to using one of the many Ajax frameworks available to us, because it is so much easier to do than actually writing all of the Ajax code from scratch. Why write a bunch of convoluted JavaScript when I can just add a property to a function in my server side code to tell a framework to make it available on the client? For designers and front-end coders (NOT developers, mind you), they have little to no experience with some of the key aspects of Ajax, specifically XML, XSLT and all of the server-side programming required to perform something using Ajax. And they are likely to only have a minimal amount of experience with JavaScript and the Document Object Model (DOM). They may be adept at doing some things with JavaScript, but, like I mentioned above, using JavaScript alone to change the content on a page is not Ajax. Also, because of the inherent technical aspects of Ajax, I find it hard to believe that these companies looking for front-end coders (as opposed to full-fledged developers and software engineers) really want those people implementing Ajax anyways.

Ajax is Not as Important as Some Are Led To Believe

There is almost no real reason to use Ajax in most websites out there. Most websites are predicated on one or more of these key concepts: displaying content, showing ads, selling a product online. If your site is primarily for displaying content, then there is no reason for Ajax because there is really nothing dynamic about the site. If your site shows ads, you really don’t want to use Ajax (or at least minimize it to where it makes sense), because it would reduce the number of page views your site received. Since page views are still the primary factor driving ad revenue (as opposed to the better metric of time on site), you really don’t want to cut into that metric too much.

If you are selling a product (or products), yes, Ajax can be very beneficial, but only if done properly. You may notice that Amazon does not use Ajax for adding items to your cart or taking you through the checkout process. There are two reasons for this. First is because they use adding items to the cart as a means to cross-sell you additional products. Second is because of usability. Having the page actually change to something completely different shows the customer that the action they were trying to accomplish (adding a product to their cart) was successful. The most common Ajax use I see in ecommerce is when adding items to your cart – it just updates the little summary in the corner of the screen to show that an item was added. This is very unfriendly to the customer because it isn’t obvious to them that something has changed. It also doesn't really work too well in the customer workflow either, because if I just added a product to my cart, why would I want to stay on the product page I was just looking at? Wouldn't I be more likely to want to go to my cart or add some accessories for the item I just added? Or, hopefully most likely, go to another product entirely and buy additional items? The intermediate page after adding an item to a cart is a great way to facilitate all of these options. If the customer really wants to view something on a product page after having added that product to their cart, it is simple enough to use the back button to do so (or you can have a “return to product” link, if you feel it is necessary).

When to Use Ajax

There are definitely times where I do think that Ajax really is beneficial. The best time to use Ajax is when it improves users’ workflow on your site. For example, if you have articles where you allow commenting, letting a user post a reply to a comment inline, using Ajax to post the reply back to the server without reloading the page for the user, is a great use of Ajax. This allows the user to continue to read further comments without having to wait for the entire page to reload, and then force them to scroll down to where they were before in order to continue on.

I would also like to state that even on sites where you are using ads for revenue, I believe that items like this are still a great use of Ajax, regardless of the lost page views. To convince a marketing or business person that this is a good idea, the best thing to do is give them numbers. For example, if an article gets 10,000 page views in the first week, and a total of 100 comments on it (a really high number for most articles), then switching it to use Ajax for commenting would only result in a 1% loss in page views for that page. However, because there is minimal delay for the users that post comments, there is a much stronger possibility that they may continue to view another page anyways, since they will now have more time available to them. In addition, that 1% loss becomes smaller still as the page lives on forever, but commenting rates drop significantly the longer an article is available online. A very small loss in page views is definitely worth it when the usability of your site is increased significantly by the change.

Another great time to use Ajax is if you are building an actual web application, as opposed to a website. Ajax does allow you to more closely replicate the functionality of a standard non-web based user interface. The basic Google Calendar functionality is a good example of this. I can add an event to my calendar by just clicking on a time block and typing in text. This functions almost identically when compared to what I do in Microsoft Outlook. The most successful web apps are those that are the easiest to use and have the best functionality. One of the best ways to do this is to mimic the functionality of desktop-based counterparts.

Conclusion

I hope that now, after reading this, you have a better understanding of what Ajax really is and when it should and shouldn't be used. Like any new or emergent technique or technology, Ajax is currently in the phase of misunderstanding and misuse (and overuse). Only with a continued spreading of knowledge and understanding can it reach a level of maturity where it is used properly to provide great experiences for the user. If you disagree with me on the right and wrong times to use Ajax (or anything else, really), please feel free to comment below. I look forward to any discussions that we may have.

Posted to Blog