BT

New Early adopter or innovator? InfoQ has been working on some new features for you. Learn more

Five Common Ajax Anti-Patterns

| by James Kao Follow 0 Followers on Mar 31, 2007. Estimated reading time: 2 minutes |
Based on his experience working with Ajax developers in the field, Jack Herrington has written  in-depth about common pitfalls in Ajax code, calling out five specific problems he sees often enough to consider anti-patterns, summarized here:

Polling on a timer when you don't need to
. While JavaScript has timer functionality (via window.setInternval() usually), it should be used sparingly. Animations are a valid use, but other uses should be carefully checked. One definite red flag is the use of a timer to watch for a request to finish. Callbacks should be used instead of polling.

Not inspecting the return results in the callback. When using the processReqChange()callback on the XMLHTTPRequest object, the readyState and status fields of the callback argument need to be checked. The callback will often be invoked before the results are complete. Failing to check this result can cause errors if code tries to process incomplete data.

Passing complex XML when HTML would be better. Formatting XML into displayable HTML in the browser can require a lot of JavaScript, which exposes developers to more browser incompatability issues. As a rule of thumb:
As with everything, the choice between whether to process on the server or on the client depends on the demands of the job. In this case, the job was relatively simple: Put up a table of movies. If the job were more complex -- perhaps with sorting, searching, adding or deleting, or dynamic interaction in which clicking a movie brings up more information -- then I can see going with more complex code on the client. In fact, I'll demonstrate sorting on the client at the end of this article, where I talk about the counter-argument of putting too great a load on the server.
Passing XML when you should pass JavaScript code. Simply put, don't use XML when you could use JSON:
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 Simple single-page functionality, like sorting a table, can be more quickly and efficiently done in JavaScript rather than on the server.

Rate this Article

Adoption Stage
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread
Community comments

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Discuss

Login to InfoQ to interact with what matters most to you.


Recover your password...

Follow

Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.

Like

More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.

Notifications

Stay up-to-date

Set up your notifications and don't miss out on content that matters to you

BT