Monday, April 2nd, 2007

Five Ajax Anti-patterns

Category: Ajax, Editorial

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?

Posted by Dion Almaer at 6:30 am
11 Comments

+++--
3.6 rating from 58 votes

11 Comments »

Comments feed TrackBack URI

I am not sure that the client versus server issue is that complicated a question when taking a progressive enhancement view to ajax and dhtml implementation.

Many applications core functionality is suited to server-side but could be optimised by client-side involvement (for instance a sort on a datagrid). You end up with implementation in two different languages but at least you have a way out (it still functions without javascript) if you find a user with an old or obscure browser who trips a cross browser compatibility issue.

Comment by wioota — April 2, 2007

Ineteresting… tnx

Comment by спортивные магазины — April 2, 2007

This really is the bare minimum – what about other http statuses like 304 (if the resource is loaded from cache I think…) – what if you’re running the file from your desktop…

Also where the IE ActiveXObject is instantiated the recommended progids should be used, which I think are Msxml2.XMLHTTP.6.0 and MSXML2.XMLHTTP.3.0 (I also fall back to Microsoft.XMLHTTP but I’ve found it buggy – most would/should have MSXML2.XMLHTTP.3.0).

Using javascript (JSON) is OK for most applications but handling linefeeds, quotes et al can be tricky – probably easier in XML/(X)HTML -also debugging a very large JSON object thats ‘fallen over’ is a pain. Also I believe (but I haven’t checked) the JSON object in the example should have year and name in quotes (“year” or ‘year’).

Another anti-pattern could be not cleaning-up the XHR objects – so IE leaks.

Just my 2p.

Comment by wukfit — April 2, 2007

I’d add: Offer a Non-Javascript version where possible.

What I don’t like about AJAX-sites is the inability to save a URL to a AJAXy generated view (list, whatever).

Comment by Sascha A. Carlin — April 2, 2007

Interesting but it’s some low level anti pattern for those who wants to make raw XMLHttpRequest…

There’s plenty of framework that does well writen ajax call so why re-discover the wheel…

Some higher level anti pattern would have been more usefull… (ie what we shouldn’t do with ajax)

Thomas.

Comment by Manson Thomas — April 2, 2007

These are beginner-level anti-patterns at best – most of these should be obvious to any web app developer worth their salt, and yet the article is rated as intermediate…

Comment by Jason Bunting — April 2, 2007

Got to agree with you Jason – Thats the point I was trying to make.

Plus if you are going to write articles at least follow standards and or best/recommended practises e.g. using the correct progids for the ActiveX Object, quoting strings in JSON etc…

Beginners might look at this article and copy the way the code is written – thinking that “this is the way to do it” because the guy who wrote it is an expert and it’s published by IBM…

Comment by wukfit — April 3, 2007

I agree with what Jason said generally, however. The article is very well written (with the exception of a couple of blemishs, wukfit) and would be a great introduction to developers – Yes I said developers, I use ASP.NET. I realise we’re not as cool as Ben’s Java “Engineers”. – starting to play around with Ajax.

I found the article nicely reaffirming, not something a feel a lot of the time.

@Manson: Why are so many people against re-inventing the wheel? You need to read Foundation by Issac Asimov. I personally try and re-invent the wheel with every new project that comes along. I do it in order to learn, keep different techniques fresh in my mind and to prevent the galactic empire from regressing to pre-atomic power.

Comment by Richard Kimber — April 3, 2007

I agree somewhat with you, Richard.
For learning, you have to implement the wheel but not when you are developing.

Comment by nitinpai — April 3, 2007

Learning (as well as the empire) is part of it. I think you and your code is at risk of stagnation if you’re not constantly questioning why you write each line of code. I accept that this is not practical in all situations, but should be done as often as possible.

Comment by Richard Kimber — April 3, 2007

I don’t see these as real anti patterns because the definition of patterns surely doesn’t fit to these (nor does anti-pattern). If you really wnat to have a pattern discussion on this level, you could add

“don’t do too much on the client”, which is similar to the “don’t do too much on the server”

In general the usecase and the problem will determine the technology and the implementation. So you cannot say that the server is bad and the client is good and vice versa. Same for the message load, which could be faster with server side generated HTML, but also – in some cases – with JavaScript objects that then are parsed on the client.

I woudl try and stay away from coining patterns that aren’t general patterns. No matter if they are good or bad practices.

Comment by Frank Nimphius — April 3, 2007

Leave a comment

You must be logged in to post a comment.