Sunday, August 5, 2007

Five Ajax Anti-patterns

I have liked Jack Herrington since I read his book Code Generation in Action which is one of the very few pragmatic treatments of the subject (no dumb MDA there!)

Jack has recently written up his thoughts on five Ajax anti-patterns which are:

Polling on a timer when you don't need to

Beware window.setInterval() code. Jack rips apart a simple example, and ends up with a nice usage for autocomplete.

Not inspecting the return results in the callback

Check for if (req.readyState == 4 && req.status == 200 ) {. That being said, I would argue that for almost all cases, you shouldn't be writing directly to XHR. Use a framework. There are a couple out there these days.

Passing complex XML when HTML would be better

"I don't want to send back HTML as I want to be pure". There is a place for talking XML, but often life is easier if you just speak HTML and innerHTML all day.

Passing XML when you should pass JavaScript code

The benefits are clear. In this example, there was a 52% savings in the size of the data blob downloaded to the client by going with the JavaScript language. There's a performance increase, as well. It was 9% faster to read the JavaScript version. While 9% might not seem like a lot, just remember that this was a fairly rudimentary example. Larger blocks of data or more complex structures will require more XML parsing code, while the JavaScript code will remain unchanged.

Doing too much on the server

There is always a balancing act on the client vs. server question. Often more of an art than a science.

What do you think? What are anti-patterns that you see out there?

No comments: