Summary
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.

Advertisement

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.

Jack proposes a script-centric approach as a smart idea - get the server to generate Javascript, and then use eval() to execute it when it comes in.

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 always feel old fashioned when saying this, but I think good ol' remote scripting is a lot more powerful when doing stuff like this. i.e. having a hidden form submit target a hidden iframe and have the returned page invoke javascript that modifies stuff in the top level document (usually just replacing a chunk of the dom with a chunk from the returned page).

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.