The last months I found more and more web sites that make a heavy use of AJAX to be on the Web 2.0 train, but a lot of them are very strange because they are slower than before, you will get more errors and sometimes nothing does work (i.e. when running on a mobile device). Here are my top 10 mistakes when using AJAX (not depending which framework you want to use):
<li>Don't use AJAX to update the complete page by putting everything in a UpdatePanel. You want to save time and traffic when running the web page. Never update parts of the web site that can be changed using JavaScript and DHTML (DOM).</li><li>Have in mind that there are a couple of visitors that have JavaScript disabled or using a web browser with an older or less JavaScript implementation like the most mobile devices have. What does your visitor see if everything is disabled? I don't recommend to have the full web site available as a JavaScript disabled version!</li><li>Cache the same requests on client-side web browser or implement any caching on the web server. The most used scenarios like AutoComplete or DropDown fields are filled everytime the same. A wrong written AutoComplete can slow down your web server (database server) because there more requests done than the version before using PostBacks. Think of pressing F5 (reload) all the time with your old web site. If you have cascading DropDown you can save more traffic/requests!</li><li>Don't run concurrent or long running AJAX requests when using CSS or JavaScript to change the UI. There are only two concurrent http connections possible with all common web browsers (I know you can change this, but the default behavior is set to two). If there are running to many AJAX requests running loading of images will be slow down.</li><li>Use everytime the asynchrouns invoke of the send method of XMLHttpRequest. There is no issue where you want to use the synchronous one. Your web browser will not be forozen when having network problems or slow connections.</li><li>Try your web application using a very slow internet connection. Try it again using a TCP/IP connection with a very high latency for each paket.</li><li>Is your web application running as a desktop replacement? Have a look at the memory usage of common web browsers if you run your application one hour, two hours or couple of days. Not everybody has a development machine like yours!</li><li>Check the http status code you will get back from XMLHttpRequest. There are a couple of common network errors like DNS not available, http server error 500. Did you ever checked for the status code which tells you if your web browser is in offline mode?</li><li>Try to disable the XMLHttpRequest object! With IE7 you can use the native object instead of the ActiveX object, but you can still disable the native object, too.</li><li>Check your AJAX requests for security issues! Did you simple open all your data access layers? Make use of FormsAuthentication and PrincipalPermissions on ASP.NET. Can anybody create requests (not only by clicking on a link)?</li> I know there are more issues where we should have a eye on. My experience is that there is a high need for deciding where and when to use AJAX.
Updated Nov 21, 2006:
Dave wrote in his comment below about some more mistakes, here are my comments:
<li>A loading indicator is, of course, very important. This should be added to requests that are slower than usal and to actions that need more time (not requests that are running long time on the server, see above).</li><li>The back button is not very easy to talk about because it depends on what you are doing with AJAX or Web 2.0. If you do complete page updates (so you replace the common page refresh only) you should have an option to use the back button. In a lot of web applications I've done there AJAX is more used to update monitors, run some actions like delete, save,... and there a back button is not needed. The UI should implement there an undo feature i.e. instead.</li><li>A machanism to cancel a requests often isn't as easy as simple call the abort method on XMLHttpRequest because the requests is already running on the web server. The same will happen when you close your web browser during a request. So, there is a need for this but my opinion is that it is not very easy to implement.</li><li>The last issue Dave is talking about is a application feature which is interessting, but is not a Web 2.0 or AJAX related new issue, everyone is interested in script errors.</li>