[Update 2011: OK, so back in 2005 I was skeptical of AJAX. At the time you needed to truly be able to write javascript in order to deal with the browser compatibility issues. The situation with the GAP site failing was a major foobar on their part and showed how much effort it took to do AJAX appropriately with things like graceful degradation. Today of course we have one of the most awesome libraries in jQuery. Which handles all the nastiness of browser problems for the most part. Today it is possible to do things with jQuery that really lead to fantastic interaction experiences. There are many other fine JS libraries and frameworks, but jQuery has really solved the problem in a way that simplifies and yet still provides powerful control to the designer/developer.]
Original Article:
Recently, I’ve had conversations with a few of my developer friends who are all a twitter about AJAX. Saying how great it is and all the cool things Google is doing with it. Honestly, after taking a real close look at it, I find it to be hardly more than another buzzword. It simply does not offer anything of real value for web development. Yes, it can make interfacing with certain web applications smoother, and it solves some problems inherent in web applications. However, it introduces a whole set of other problems, that in my opinion, make it widely unsuitable for most work.
First of all AJAX is Asynchronous JavaScript and XML, a bunch of older technologies combined in a “powerful” new way. As indicated, Ajax makes use of XML, specifically the XMLHttpRequest object to manage asynchronous connections from the client to the web server. For most basic uses this can accomplish some really cool things… Things such as Google Maps, where you can zoom in and move the map around dynamically as data is moved from the server to the client behind the scenes. As cool as Google Maps is(are), Mapquest and Yahoo maps work just fine without AJAX, and what is more, provide more information for important things like directions. I recently tried to use Google Maps for directions and they were completely inaccurate, If I hadn’t been somewhat familiar with the area I would have been lost.
My biggest complaint with AJAX is the Javascript part. As it currently stands, the Safari web browser does not support all the javascript that AJAX requires in some cases. An excellent example is GAP.com. They recently redesigned their site with heavy use of AJAX and if you visit with Safari, you get a page that says sorry please use Mozilla/Netscape. Creating web sites that lock out what is arguably a major browser is so 90s. Many Mac users thought that they (GAP.com) were not standards compliant, the reality was that the site is standards based, but the use of AJAX to update the shopping cart and display certain product info, does not work in Safari (or Opera).
Now the GAP developers could/should have done the âdegrade gracefullyâ thing and made it so that it would work in browsers that donât support AJAX, but that is extra work. Alternatively, the Safari developers will likely implement the needed javascript support in future releases, but then there may be other things javascript wise that require extra code to make work in IE, Mozilla, Safari, and Opera, or may not work at all. You can go look at what this person considers 10 of the top Ajax applications and see how many work well, and if you use a Mac with Safari see how many you can use at all.
Using Javascript with or without XML is a pain most times. I remember back in 1999 when DHTML was the big thing in web development. It was really cool, but right from the start there were incompatibilities and having to deal with the major suckage of browser detection, and well, DHTML was almost forgotten until this AJAX crap came along. Javascript was relegated to mostly minor things or done in a way which allowed for “graceful degradation”. That is where you wrote the code so that it also works in browsers that don’t understand the Javascript. Now comes AJAX and we have a bunch of web apps that mostly only work on windows computers and in some cases only IE.
For sites that sell products or services this is simply not acceptable. It might be OK for an intranet or for something provided free (as in all things Google), but when customers pay, it is not wise to do anything that impedes them from reaching into their wallet and giving you money. Of course, the GAP developers may argue that it works in IE and in fact makes it easier for the 85% to give money to GAP. It all comes back to how long/likely will that remain true. Just ask all the folks who built sites that worked best in Netscape in the 90s and you will learn that the browser market is not something you want to bank on. I would argue that they have not made it any easier for the 85% who are IE users and did not really gain anything.
Other AJAX problems include the fact that it is still a client/server interaction… network glitches, slow connections (dial-up users are still out there) will cause any AJAX app to flounder, if not fail just like any other web app. You can still outpace the data flow of an application. As an example, go to Google maps and zoom or move it around as fast as you can and you will see glitches. In fact, if you are on a slower connection you may get map image parts that never load because the mapping engine has moved on to load other data. If you look at the graphic outlines provided in Jesse Garrett’s essay on AJAX you can see the layer of complexity that AJAX adds. Simply, the effort to make something work as an AJAX implementation and then also work as a basic web app is not worth the time or effort for most organizations.
Having said all that, I do think AJAX has its purpose. It seems to me the best use of AJAX is where you do want some cool interaction, on a non-mission critical application. If you do use it, whether for a mission critical app or not, one must be very careful to pay attention to the details of the interaction. Particularly, making sure to use AJAX in ways that also create effects to inform the users of what is going on… as it is easy to use Ajax in ways that the user will not notice, particularly when/where it is important for them to notice. Again, to me, a web application is only useful if it works for the widest possible number of clients. If you have very tight control of the audience/browsers such as a corporate intranet, then you may invest in the effort to use Ajax, but don’t be surprised to find that your corporate users are not as homogeneous as you think. Personally, I have not found a need to use it in any of my projects, and I am not inclined to start introducing it just to satisfy the itch. To me, developers who run off to implement some new geegaw often lose focus of the real purpose of a site and usually end up with something that may look spiffy, but is a headache to maintain and/or only works in a particular browser and ultimately fails (partialy or completely) for the audience you most want to reach.
I acknowledge Ajax can deal with some web app problems in very useful ways. A long standing problem with basic web applications is the session and state management of interactions between client and server. AJAX can be used to solve those in ways that were not easily done with basic web apps. Ardent supporters of Ajax will argue there is always going to be some browser problems that no matter what you do. So using AJAX may not be a a bad thing at all. In the end, if your organization has the resources to throw at using AJAX, go for it. Especially, for something that doesn’t necessarily deal with e-commerce or mission critical services. Otherwise, you can file it in your buzzwords file and move on to more important problems… like fixing all the accessibility problems your (and mine) site still has.
For more reading, you can read the following reference links to learn more about issues with AJAX;