As Ajax and rich-client applications become more common, typical Ajax anti-patterns are emerging: Patterns of code and techniques that developers would do well to avoid. In his latest IBM developerWorks article on Five Ajax anti-patterns, Jack D Herrington describes why using a timer for polling is a bad idea, and why bad choices in dividing the work of client and server can lead to poorly performing applications:

• Polling on a timer when you don't need to

  Many of the Ajax issues I see have to do with misuse of the timer functionality built into the JavaScript language. The key method is window.setInterval()... [that] tells the page to call back a particular function on a particular interval—say, every second... When it comes to these timers, [browsers] rarely deliver, primarily because the JavaScript language is single threaded. If you ask for a second, you might get the callback at 1 second or 1.2 seconds or 9 seconds or any other time.

  Ajax is asynchronous by its very nature. Don't you need a polling loop to see when a request is finished? It turns out, not so much... All the XMLHTTPRequest object provides is a callback mechanism called onreadystatechange.

• Not inspecting the return results in the callback

  Many Ajax anti-patterns spring from misunderstanding the mechanism of the XMLHTTPRequest object. One that I often see is when users don't inspect the readyState or status fields of the object in the callback... I have noticed in Internet Explorer 7 that this problem is more acute than on other browsers. Internet Explorer 7 calls back to onreadystatechange a lot—and I mean a lot, even on small requests. So, it's worth having your handlers written properly.

• Passing complex XML when HTML would be better

  Putting a lot of intelligence in your pages means putting a lot of JavaScript code there. And that has a big downside: browser compatibility. You really should test every non-trivial line of JavaScript code on every popular browser—or at least, the browsers that your customers are likely to use. And that means work... Wouldn't it be simpler to have the server return HTML instead of XML? ... The choice between whether to process on the server or on the client depends on the demands of the job.

• Passing XML when you should pass JavaScript code

  With all the hype about having Web browsers read XML data sources and dynamically render them, you might think it was the only method available. However, you would be wrong, because very smart engineers have used Ajax transport technology to send JavaScript code instead of XML... Instead of reading XML from the server, [the client] reads JavaScript code. The code then uses the eval() function on the JavaScript code to get the data

• Doing too much on the server

  A counter-argument to doing to little on the server is doing too much on the server. [You can, for example do on the client] table that sorts quickly, without a page refresh and without bothering the server to do the hard, uninteresting work of the sort.

What Ajax anti-patterns have you observed?