Five AJAX Frameworks Reviewed

prostoalex writes "Dr. Dobb's Journal reviews 5 AJAX frameworks: Dojo 0.3.1, Prototype and Scriptaculous 1.4, Direct Web Reporting 1.0, Yahoo! User Interface Library 0.11.1 and Google Web Toolkit 1.0. Each framework was tested in two basic scenarios — writing a 'hub' (titled collapsible link list frequently seen on sidebars of many Web sites) and a 'tab panel' (horizontal tabbed navigation bar). During the process, Dr. Dobb's Journal reviewers noted that 'Dojo provides more features and HTML widgets than YUI and Prototype' but eventually 'settled on the Yahoo! User Interface Library.'"

Comments

Frameworks versus Libraries

[dmeranda]

This sounds like the classic Framework versus Library debate. Some good reading:

The Dojo mailing list thread "dojo: framework vs library"
http://dojotoolkit.org/pipermail/dojo-interest/200 5-May/000231.html

Joel Spolsky's "Why I Hate Frameworks"
http://discuss.joelonsoftware.com/default.asp?joel .3.219431.12

Arnon Rotem-Gal-Oz's "Frameworks vs. Libraries"
http://www.ddj.com/blog/architectblog/archives/200 6/07/frameworks_vs_l.html

That being said, there are plenty of features in Prototype which are more library-like than framework-like, so it is easy to use parts of it without buying into a whole framework methodology. I don't know much about the other evaluated tools.

jQuery, too!

[sbma44]

It takes the magical $() selectors of prototype, expands on them, and somehow delivers it all in 19k.

Another good option

[cabinetsoft]

is jQuery and it's plugins.

Old News?

[russcoon]

I'm Alex Russell, Project Lead for Dojo,

We're obviously flattered that our little project got covered in DDJ, couldn't they have reviewed newer versions of the tools they covered?

AJAX frameworks are NOT pointless

[francium de neobie]

There are many little funny things that just happens when you're coding a web application in JavaScript without a framework/library/toolkit helping you. Unless you're really an AJAX/JavaScript wizard, coding an AJAX-enabled web application on your own and mixing online code receipts is a very dangerous thing to do.

Browser inconsistencies
This is the most obvious one, but only the entry to the rabbit hole. If you are not familiar with the example (maybe not exactly the same, but any AJAX web developer worth his salt should have seen one like that) I give below, then please, PLEASE, do yourself, your fellow developers and your users a favor, resist the urge to hack things together for once, use a mature AJAX framework.

An important part of AJAX is that you need to update what is displayed on the web browser in the client side (by JavaScript), without refreshing the page. This implies that you're very likely to have to create and destroy DOM nodes on the fly. Now, how do you create a radio button in JavaScript?

How about...

var node = document.createElement("input");
node.type = "radio"
node.name = ...
node.value = ...

That's what you would do if you follow the DOM standard. But sorry, this does not work. Try to create a radio button with the above code segment in Internet Explorer 6, you'll get a broken radio button - you can't select it. The correct way to create a radio button by DOM manipulation is described in this MSDN article:

newRadioButton = document.createElement("<INPUT TYPE='RADIO' NAME='RADIOTEST' VALUE='Second Choice'>")

Memory leaks
The last one was easy. Do you know you can make a web application that leaks memory like a sieve in Internet Explorer 6 by making a simple circular reference like the following one?

var node = document.createElement("div");
node.someAttr = node;

If you're a good programmer, I might have sounded an alarm in your head right now - any circular references involving DOM nodes in IE6 results in memory leaks that persist after URL changes or page refreshes - unless you use an AJAX toolkit that takes care of the issue for you. Have you assigned a DOM as an attribute value under another DOM node in the past? Yes? Then you'd better check your web application for memory leaks with Drip, now.

What's more, it's not just assigning DOM nodes as attributes that would result in memory leaks, closures in JavaScript can also form circular references and cause memory leaks. What makes closures particularly dangerous is that circular references with closures are not easy to spot. For example, the following code segment leaks:

var node = document.createElement("div");
var clickHandler = function(){};
node.onclick = clickHandler;

Looks innocent enough, but you've already formed a leaky circular reference here. node->clickHandler->node.

For more information about memory leaks under IE6, read these:
Mihai Bazon's blog entry
MSDN's lengthy and confusing description of the problem


The XMLHttpRequest object is not as simple as you think
Much of the magic of AJAX comes from the XMLHttpRequest object (or its ActiveX equivalent, or an iframe, etc.), right? Sure. If you're only doing something simple via AJAX (like, updating the server time), then you can just copy an XMLHttpRequest code snippet from sites like this and hack away, right?