When NOT to use AJAX?

The recent AJAX hype has lead to the belief that AJAX is a Good Thing. Without saying it is a Bad Thing, I do think in some cases it is being used for inappropriate purposes. It requires some explanation to tell when it's appropriate and when it's not. The main point being made here is that AJAX is an unreliable technique. I don't mean the word "unreliable" as negative as it may sound. It just means the technique should be treated with special care.


What makes AJAX unreliable?

Two things: the fact that it is JavaScript and the fact that it is Asynchronous.


Why is JavaScript unreliable?

First of all a rough 10% of web site visitors disable JavaScript. An increasing number of RSS readers like RSS Bandit tend to disable JavaScript in their browser component for security reasons by default. This means you cannot rely on the availability of JavaScript and you should ensure your web application is still accessible without JavaScript.

If JavaScript is enabled, it's still a common weak point in web applications. There are subtle differences between JavaScript implementations through several browsers and versions. It's a tough job to test through all browsers, versions and operating systems. It is recommended to stick with the standard JavaScript functionality that has been around for a long time and not to use browser specific features.

JavaScripts are error prone by their nature. JavaScript is dynamically typed and uses weak typing. Dynamic typing means variables are not explicitly declared with a type; instead all variables are a "var" and get a more specific type on initialization. Weak typing means that once a variable is initialized, it can still change types when needed. Strong typed languages (regardless of whether they are statically or dynamically typed) generate an error message when programmers forget to perform proper conversion of variable types.

The lack of error messages is a tricky part. An essential programming philosophy is the Fail Fast principle. The basic idea of this principle is that when something goes wrong, a program does not try to continue working. It should stop and display an error message. Contrinuing working after an error is very risky because it is unpredictible what the program will do after the error. To a web site visitor it is better to display an error message with an indication whether it makes sense to try again, come back tomorrow, install new software or go to a church and pray. In consultancy this is called "managing expectations". Telling the visitor it won't work is better than letting him continue working for 30 minutes and then find out the 30 minutes were a complete waste of time.

Implementing the Fail Fast principle in JavaScript is not easy if not impossible. The error handling mechanisms in JavaScript are very poor. Most of the time the best you can get is "something went wrong". In more sophisticated languages like Python, Java and C# you can get specific exceptions with stack traces leading to the exact point of failure. This is one of the reasons why I'm very glad with Microsoft's transition from ASP Classic to ASP.Net. Compiled dotNet code is much more stable, predictible and easier to debug than VBScript based ASP Classic.


What's wrong with Asynchronous code?

Nothing really, as long as you don't forget it is asynchronous and asynchronous is unreliable by definition. The difference between synchronous code and asynchronous code is the predictibility of the server response. A synchronous request blocks until a response is received. If the response times out, you get a clear error message. As long as you don't introduce multi-threading yourself, your code is completely predictible.

In contrast, asynchronous code continues working without knowing when the reponse will be received. If your code depends on the response, you need to build in a system that checks the status of the response before it starts executing. The risk is that while developing and testing your server responds so fast that you forget the possibility of not receiving a response. Building a system that checks the status of a response makes your code complex and hard to maintain. Building such a system goes against the nature of asynchronous requests. It means you're using functionality for a purpose it wasn't meant for. Denying the nature of a technique is a Code Smell. This means you should consider doing things in a fundamentally different way.


How can I still use AJAX?

You should have a clear understanding of why you need AJAX. AJAX is not a goal, it is a method to achieve a goal. What is your goal and why is AJAX the appropriate solution? Are there alternatives? Is there a backup method to fall back on when it doesn't work?

AJAX is a client side technology. As with all client side technology, your server should be developed in a defensive way. All client side checking of form input should be rechecked server side just to be sure. Also, in the absence of client side support for AJAX technology, the server should provide functionality to fall back on so the web application keeps working.

The most popular reason for AJAX is performance. AJAX reduces the load of traffic between client and server and reduces the need for page reloading in the browser. This is good as long as the page reloading method still works. Google suggest is a good example. Google still works when the suggest-feature is not available. It is very user friendly though that the feature is there when the browser is able to process the scripts and the server responds in time.

AJAX can be very helpful when providing early feedback on a form filled out by a web visitor. For example a registration form can warn that the username chosen by the visitor already exists before the form is submitted. This saves time. As long as the server checks the username again on form submission, this is proper use of AJAX.

Inappropriate use of AJAX would be if a search engine decided all search results are loaded through AJAX and classic form submission would no longer be possible because it would be slow anyway. Inappripriate usage would be if a drop down menu in a form depended on content provided by AJAX depending on earlier input in the form. Even though this might work in 98% of the cases, it is no proper way to provide your services to your visitors.


Conclusion

More general, what this article says about AJAX, can be translated to any client side technique. You should also be careful depending on client side technology when it's Flash, a Media Player, browser versions or devices. Making assumptions about client side features has been one of the main causes for irritation by visitors of many web sites. Of course there are differences between personal sites, entertainment sites and company or government sites. Especially in the last case, special care is required.

When NOT to use AJAX? Do not use AJAX when you depend on it. Use AJAX as an additional feature to spice up your web application and serve your customer.

AJAX | JavaScript