Anti-patterns aim to define design and coding practices that developers do well to avoid in a problem domain. Jack Herrington describes five Ajax anti-patterns in his latest IBM developerWorks article.
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
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
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.
There's a great anti-pattern lurking within here, where the server generates lots of low-level JS, referencing DOM nodes by name, minor variables and function names, and so on, creating a very tight coupling between client and server tiers. If you're going to adopt this approach, please define a high-level API for your generated server code to talk to. (Jack, as ex-editor of the code generation network, will already know this, as its one of the core tenets of code generation to generate against as high a level of abstraction as possible).
I've never quite been able to figure out why this has fallen out of favour - I've written a lot of funky well performing web apps like that.