Be aware of AJAX's drawbacks

AJAX combines the power of existing Web technologies to build powerful user interfaces that offer benefits often found in desktop applications. Over the past couple of years, Web developers have embraced AJAX in their own development efforts as well as via third-party toolkits.

Once you use an application built with AJAX, it's easy to see the benefits: the user experience improves, as page reloads are reduced, and features such as automatic type-ahead facilitate data entry.

Some developers view AJAX as the silver bullet for every scenario. However, AJAX introduces its own set of hazards in various areas, which include: development time, browsing history and experience, search engine interaction, accessibility, server load, and security. Let's take a closer look at each of these areas.

Development time

It usually requires more development time to build an application using AJAX than using other approaches. Plus, learning a new technology like AJAX provides it own set of delays before properly understanding and using it.

Since it is a core feature, the amount of JavaScript contained with a page increases when an AJAX solution is tackled. Consequently, developers must be knowledgeable in JavaScript and related cross-browser quirks; as you probably already know, not every developer is especially fond of JavaScript. In addition, developers must be proficient in HTML and XML, as well as other technologies like CSS for style.

Another issue with JavaScript is that you have to consider what to do when a user has disabled JavaScript support within their browser. This requires extra development time to deliver an alternative solution (using the NOSCRIPT tag).

In addition, when developers jump on the AJAX bandwagon, you should make sure that they don't use it for everything.

Browsing history and experience

The Really Simple History (RSH) JavaScript library highlights another major issue with Web applications that use AJAX: There is no browsing history, so Back/Forward buttons become useless. The lack of a browsing history emerges from the dynamic nature of an AJAX solution. Data is loaded asynchronously without a page reload, so no page access is recorded in the browser history. This means that users are unable to easily bookmark or navigate to and from the application using the browser's buttons. RSH provides one way to build such functionality into an application, but it will add development time and testing.

Search engine interaction

Another issue emerging from the dynamic nature of AJAX is a lack of interaction with search engines. Search engines like Google require a page URL and use words on the page as one aspect of its approach to ranking pages.

Page data is dynamic within an AJAX application. Search engine spiders do not load a page and execute its JavaScript. This results in search engines ignoring an application or a page. This can lead to lost visitors, but it will not be an issue for internal intranet applications.

Accessibility

AJAX is not the most accessibility-friendly development paradigm. AJAX makes the browser act in a way that is different than its original design; for instance, Back and Forward buttons no longer work as expected, and there is no URL for some AJAX content.

These issues should remain in the forefront as you develop an application (regardless of whether it uses AJAX). You can apply the techniques I discussed in the section about browsing issues.

AJAX is not supported in browsers on mobile phones and PDAs, so these devices can be used as a reference point for developing applications that are accessible to everyone. O'Reilly's Ajax: The Definitive Guide does an excellent job of stressing accessibility while using AJAX.

Server load

Server load and bandwidth can be an issue when delivering AJAX-based solutions. These solutions often use AJAX to provide features like type-ahead searching in text boxes or loading data in the background. The user may see fewer page reloads, but the server calls are still there.

It is worth considering whether the backend server can handle countless simultaneous calls to the server when many users are using the type-ahead feature. An overworked server can lead to an interrupted user experience with lags in loading data asynchronously. Displaying interim messages like "Loading" can alleviate user concerns because this lets them know something is happening rather than being presented with a blank page.

Security

Security has always been an important issue with Web applications, and AJAX is no different. Like any other application that uses the HTTP protocol, data is sent as clear text. For this reason, no sensitive data should take a ride via HTTP using AJAX or any other technology.

While JavaScript is a mature language, it does have security holes that must be recognized regardless of whether you're using AJAX. Server-based security measures can be used to block such problems. Also, the issue of cross-site scripting -- XSS is more pronounced with AJAX, as script may run in the background and access resources without user knowledge. Given these possibilities, all data must be protected to avoid malicious activity.

Make a well-informed decision

There are times when AJAX is applicable, and there are times when you should choose another approach. Be sure to consider potential issues with AJAX before putting it to use in your next application. A hybrid approach is usually the best solution with AJAX because it provides certain features in the user interface and other technologies used in other facets of an application.

Is your organisation embracing AJAX? What, if any, problems have you encountered with delivering AJAX-based solutions? Share your experience with the Web Developer community.