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.'"

Frameworks

Am I the only one who usually finds frameworks to be pointless for serious web development? It's not that they're necessarily bad, but that they pack in dozens of features that you don't necessarily need (potentially bloating the size of your page download by tens to hundreds of K) or even want. In many cases, the frameworks have a ton of little "gotchas". For example, Prototype has a set of functions that are supposed to make it easy to show and hide elements. The only problem is that if you define the "display" element in the style sheet (say, to make an element invisible by default) you can't change the element's state. This is because the Prototype library works in a stateless fashion, assuming that the default value for "display" is the way to make an item visible. Which may not be not be true.

Other libraries have some cool GUI widgets, but often those are actually too much for a project. In some cases they even require you to build the entire project out of their widgets! That's nice if you're writing the next Outlook on the Web, but not so nice if you're trying to add interactive elements to an existing webpage. Especially if you like the more open HTML design rather than the cluttered pseudo-GUI design.

In general, I've found that these libraries may be kind of nice if you're not too familiar with DOM/CSS and want to perform some neat effects. (Scriptaculous in particular does some nice effects without a whole lot of difficulty. Just watch the download size!) But if you're doing a complex website, you'll probably be better off with a custom library for now. At least until some standard practices emerge among professional sites.

Now if you want to talk about libraries that patch minor browser issues like no DOM 2 Events, lack of Object.toSource, unified XMLHttpRequest instantiation, etc., then I'd have to jump in and add glowing support for such pieces of code. The key is, though, that they're very passive libraries. You include them, and they make sure that your code works the same everywhere. Which is a bit different than being forced to structure your project around a framework. If there's one thing I love about Javascript, it's that everything is virtual. ;)

Re:Frameworks

And I could show you inefficiencies and poorly-formed code and design patterns in projects that do use Struts/Shale/WebWork.

That's not to say that frameworks aren't useful for some purposes, but "enforcing well-formed code and design patterns" is not one of those reasons, nor is failing to use frameworks evidence of bad design.

Re:Frameworks

Frameworks are what professionals use - the enforce well-formed code and design patterns.

Funny thing, though. We "professionals" (I like the insinuation there, BTW) use the right tool for the right job. Sometimes the right tool is NOT someone else's framework. Sometimes, you're actually creating inefficiencies by adding layers unnecessary to the project at hand. Only an amateur selects a server-side framework before knowing the requirements of the project. The "professionals" will use off the shelf if it makes sense or build their own if better results can be achieved.

In the case of Javascripting, you've got a lot of factors working against you. The first is size. You can't afford waste, because you're trying to ensure that the page renders as fast as possible. Dumping 100K+ from the scriptalicious framework just to fade out a single box isn't very effective to your budget. Especially since the same effect can be achieved in a few hundred bytes by using a custom framework.

The second factor working against you is reusability. Javascript is not very well designed to handle this area. Object Oriented concepts we take for granted in Java (interfaces, abstract classes, private methods, final assignments, etc.) are not enforceable in vanilla Javascript. So you have to either be really clever (sounds like trouble), or work through standardized practices.

The third factor working against you is maturity. These frameworks are of varying levels of maturity because such web technologies are anything but old-hat yet. There are plenty of situations they are untested in, potentially leaving you debugging someone else's code rather than moving your project forward. Thus a framework may actually increase your project time if you're not careful.

And with that, there's one last note I'd like to point out. Frameworks are far too often chosen as a crutch rather than a time-saving component. Make sure that when you chose a framework, it's because you know it will do the job you need it to. Not because you heard it's the latest craze (bad), or because you have no idea how to implement the functionality it provides (even worse).

Re:Frameworks

In fact your very own logic argues for the use of a JS framework. Anything you write that relies on Prototype is going to be far more mature and reusable than something you cobbled together on your own. When I say "mature", I mean it in the holistic sense. It's very, very unlikely that you are you going find some trivial error in the core Prototype library. It's virtually certain that you would do so if you write your own. Maybe you will get them worked out by deployment time, maybe not. Second, Prototype has a rich and consistent API, and anyone who has experience writing applications on top of it could easily pick up your code and reuse it. Finally, you make no mention of cross-browser compatibility, which makes me wonder how much experience developing these sorts of applications you really have. Words cannot describe how much time you save when your starting point is something that works out of the box in IE, Firefox, Safari and Opera. You could sink literally hundreds of hours into testing your application on various platforms. Fortunately, you don't have to, because someone already did. Why reinvent the wheel?

Frameworks versus Libraries

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 [dojotoolkit.org]

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

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

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.

Re:Frameworks

Funny thing, though. I've seen more than enough situations where the framework is obsolete by the time it's done. Take Portlets for example. Seems like a beautiful idea. Web pages are composed of sections, therefore they should be built in sections, right? Right. 5-7 years ago, that is. When I built custom frameworks to good effect that did the same thing.

Today, you often need to go back to looking at the entire page. Why? Because the cutting edge developments require that the page be looked at as a complete memory model. If you try to take the HTML Component approach, programmer 1 may stomp all over programmer 2's Javascript or document ids by accident. Thus it suddenly makes sense to unify those pieces into libraries akin to more traditional programming methods.

Right tool. Right job.

Re:Frameworks

Am I the only one who usually finds frameworks to be pointless for serious web development? It's not that they're necessarily bad, but that they pack in dozens of features that you don't necessarily need

This was my problem in the open source project, partly Ajax driven, I'm involved in. Exactly for this reason it sported custom coded Javascript from the start. I don't want to load 50K+ javascripts, and I don't want one big script with crap I don't need. If you have some fairly basic stuff which doesn't change much, it's much more efficient to hand-code your own javascript. Also, when this problem arose, and it is still true, these libaries are relatively brand new, and I found it silly to commit a codebase to any of them. However, if you do all your own coding, there are problems such as cross-browser compatibility, and also there is a certain threshold of complexity when you find you're factoring out the same code and problems, and one should consider a switch. But it is a dangerous point which should be a warning sign by itself, because it could imply your stuff is getting too bloated.

It turned out jquery (jquery.com) was the best choice in our case, it addresses exactly my worries by sporting a size of just 20KB, all extras come in modules, and it's very powerful. I'd rather have a 10K version, but there you have it, you can't have it all. How it (or I) work, is to load the core when the page is loaded, and only insert additional scripts (mostly dynamic, i.e. when you click something) when needed. Similary, Yahoo! has a fine, modulized lib which is extremely well documented.

Last but not least it must be noted that all of these frameworks use MIT/BSD style licenses, and I'd like to thank them all for their great tools and generosity.

Re:Frameworks

I disagree. If your goal is to write a website for mom, it is overkill to look at Prototype (maybe). However, anybody who is comparing frameworks is probably way beyond the simple stuff.

As for the bloat issue, this is where libraries like Scriptaculous are doing it right by keeping classes of components in separate libraries. Second, this is why browsers cache JS files. Third, if you want cool effects that are cross-browser compatible, you simply have to accept that such effects come with bloat. If bloat is a show stopper, then you probably shouldn't use fading transitions with scaling div boxes anyway.

And if the argument is that these add way too much *unused* bloat, this comes back to the "mom's website" argument I made above. If people want to use machine guns to hunt cockroaches, that's their call. Unlike with a machine gun, if Prototype is too much, you can always cut out the small pieces you need. That's right -- people seem to conveniently forget that if they only really need one small, tiny part of a much larger library, they're always free to simply cut and paste that component out (MIT license is a great thing, huh).

What? But you need the rest, just in case? Then don't complain about the bloat you are willfully accepting. But in all honesty, Prototype's foot print is tiny -- about the size of an extra image banner -- and it gets cached.

I have been using Prototype extensively lately, and I have found it as a major time saver. By using it, I don't have to remember the various undocumented "gotchas" across browers. I'd much rather deal with the well documented [prototypejs.org] show/hide issue than trying to figure out how to make transparent text in all of the browsers. On that note, did you know Prototype tries to prevent the very "gotchas" you talk of? For example, stopping event propogation is the same method no matter what browser you are using, and the Element.setStyle/getStyle methods correctly convert the 'opacity' property depending on the browser being used. So for whatever "gotchas" you are using to discredit Prototype, I think you are conveniently ignoring the hundreds of others that Prototype strives to fix, silently, without the developer ever knowing.

And lastly, about the notion of writing your own custom library -- that's hardly an option for most people. First of all, most web developers are not JavaScript experts. In fact, I've almost never seen someone use exception handling in JavaScript, short of in libraries like these. More importantly, even if you were some kind of JavaScript guru, are you going to test all of your methods in all of the browsers out there? Can you guarantee your AJAX calls work the same in all browsers? What happens if I trigger a second one during the first one? Is your implementation really more efficient than Prototype's? How long is it going to take to design this custom library? Is it extensible? Does it respect the global namespace? Does it play nice with other JS files I include? Does it work in strict/quirks mode? Like I said, writing such a library isn't an option for most people. Prototype is as close as it gets to a "patch" library, which is why so many other frameworks are built on it. That, and it has been extensively tested, which is a requirement for most companies rolling out technologies like it.

MooTools

what about mootools? [mootools.net]

QooXDoo

I've had solid luck with http://qooxdoo.org/ [qooxdoo.org]

Security not a consideration?

Curious. With javascript hijacking attacks just discovered a few weeks ago, security was not a consideration in the evaluation at all.

I'm a bit disappointed.

Script# ?

too bad they didn't look at Script# [nikhilk.net] ... good stuff :-)

As a .NET developer

ASP.AJAX [asp.net]

MS's toolkit has been great - FF & Safari support is a breeze in most instances, allowing us to develop our applications really quickly

Having downloaded and hacking a few quick demos with the silverlight BETA API, I am looking forward to integrating the CLR in our future releases

My experience with Dojo

I have had an experience very close to the author's. My group at work maintains an internal app served with Websphere, just like the author. We have a tree of nodes that recently ballooned in size to 40,000 nodes and this was causing our CSS/javascript tree to choke as it loaded everything once and used the CSS to handle opening and closing of nodes. It would take about 5-10 seconds to load the tree once, but after that it would perform nicely. We wanted a near instant load at start and then whenever you expanded a node it would grab its children from the database and display them then. My coworker and I didn't have any AJAX experience when we started working on this problem so we turned to frameworks.

First think I looked at was the Google Web Toolkit, and dismissed it as quickly as the author. I suppose if we ever rewrite our app from scratch we'll maybe consider it, but not right now. Then I found dojo, and we started using that to implement a dynamic loading tree. I got it working and plugged into our database fairly quickly, but found out it wouldn't help us much. Clicking on a parent to display its children can take anywhere from 1 to 15 seconds depending on the how many children it has, and also basically freeze your browser while it's doing that. It also either had a memory leak or just managed memory inefficiently because the browser's memory footprint would balloon in size as you clicked more and more nodes.

My coworker eventually took it into his own hands and started hacking the dynamic loading himself. I've been busy with other projects so I don't know how he did it exactly, but it's a combination of our old CSS tree and some dynamic loading to speed up the initial load. Clicking on a massive parent can still cause some slow loading, but it was better than dojo. I think dojo is a great toolkit, but when you just want to pull one specific piece out of it, it can be cumbersome and bloated. Also, the documentation sucks and if I needed help, I mostly just read over old bug fixes and such. I forwarded my coworker this article so maybe we'll look into YUI.

Thanks for the session id

Generally not a good idea to not post URLs with your jsession ID in it. I love when people forward their Evite invite URLs thinking they're sharing the event invite but they're enabling people to reply on their behalf.

Where's MyBic?

A Review comparison of MyBic to these frameworks would be nice. Anyone out there that would like to volunteer?

Just don't choose them all!

Earlier this year I got pulled into a project that had been done by a team from everyone's favorite subcontinent. They had used both Yahoo and Scriptaculous /Prototype at the same time!

The site would download quickly enough, but then the page would just sit blank and churn for about 30 seconds before displaying anything.

It was hideous, and it was never getting closer to completion, so we replaced their 108 man-months worth of Ajax coding with 2 man-months worth of Flash development and everyone was much much happier. (It loads in less than 1 second and the management thinks it's cool.)

A YEAR old?

the current release of Dojo is 0.4.2

Why is this article reviewing a release of Dojo that is over a year old? And you might notice that Dojo gets the short end of the stick too.

Adobe Spry Framework...

I'm more intrested in finding out how the Adobe Spry framework [adobe.com] compares. I just got a copy of Adobe Creative Suite 3 (academic pricing is so sweet!) where this framework is part of Dreamweaver. With CS3 being so new, doorstoppers ($50+ USD books) are not yet available to explain how to implement this framework.

jQuery, too!

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

Why dojo 0.3.1?

Dojo 0.4.2 has been out for a while now, and is vastly superior to any of the 0.3.x releases. Why did they pick such an old revision of the toolkit?

Use frameworks only when really need them

You have to understand what you are using, as was discussed earlier [slashdot.org] often frameworks are not needed, simple custom script should be sufficient for most cases. However people do tend to wrap even simplest of things into large complex frameworks, supposedely for introducing commonalities, providing familiar interfaces, whatever. AJAX is just so simple that in most cases any of those would be overkill.

As the article (I RTFAd) states there are many cons and pros using these various frameworks. The main cons were:
1. Not supporting the development model chosen for the project.
2. Not providing enough documentation with the framework.
3. Not providing enough widgets (many widgets still have to be custom made even with the frameworks.)
4. The framework is too large and impacts performance.
5. The resulting code is difficult to maintain.

The pros were:
1. Not having to write the AJAX code by hand.
2. Not having to write some widgets by hand.

I would say there for those cases when it is absolutely decided to go with a framework, do mix and matching. Use the simplest AJAX framework and mix and match it with widget libraries, but not entire libraries, extract what is absolutely necessary, in all cases custom code will have to be created by hand.

Another good option

is jQuery [jquery.com] and it's plugins [jquery.com].

Old News?

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? [dojotoolkit.org]

JQuery

...I find is quite nice :)

http://jquery.com/ [jquery.com]

They all come up short

I've used them all, including moo (http://moofx.mad4milk.net/) and the toolman library (http://tool-man.org/examples/) and each one has a little something missing or fails to work well for some browser/OS combinations.

I've had to tweak or extend the code in each case, and in the end I settled on my own ajax class because none of the frameworks had a decent timeout/cancellation mechanism. For "desktop" apps I agree that YUI is the best of the lot, although I've had to roll my own extended modal message box classes because of some deficiencies in the YUI versions (some fixed in the latest rev, some not).

For "fun" GUI effects I've found prototype and its derivatives overrated. YUI works better IMHO.

However, no one beats toolman for list manipulation and editing-in-place, and for quick-and-dirty manipulation of divs as "windows" I rely on a modified version of code from that original venerable bullwark of DHTML coding, the O'Reilly JavaScript and DHTML Cookbook.

The moral of the story?

It's still the wild west out there (here?) No single library is perfect, all have some puzzling and maddening flaws, and if you're good at what you do, it's often better than not to roll your own. It's the only way you'll discover such oddities as the (just-fixed) non-standard behavior of the escape key in the Camino browser, and the lack of click input in Safari for radio button labels or Opera's handling of resized divs containing tables. Yes, these are browser problems, but a major selling point of the monolithic frameworks is that they've been tested, and that these quirks are supposed to be normalized and accounted for.

Lastly, I know the title of the post was AJAX frameworks, but ajax is actually only the smallest part of these systems. Most focus on the visual effects and "window" management features, with the ajax part kind of thrown in. To me, that's also part of the problem. These frameworks are trying to become desktop replacement libraries, only part of which involves ajax, and they're still struggling through growing pains and an identity crisis.

In a way it's all quite fun, like coding C++ was (commercially at least) back in '91, when we were still trying to figure a lot of it out. Hmmm...we're still trying to figure a lot of it out. What was my point again? ;-)

Jquery

Dojo is nice if you want widgets (month selector/accordian/...) but the documentation is rather weak. Personally I like JQuery, good docs and everything in 1 rather small file.

Umm... hello? jQuery?

"jQuery is a fast, concise, JavaScript Library that simplifies how you traverse HTML documents, handle events, perform animations, and add Ajax interactions to your web pages. jQuery is designed to change the way that you write JavaScript." - jQuery homepage [jquery.com]

jQuery is great because it's really small and really easy to use. I know very little about js and have absolutely no interest in learning all the gotchas related to cross-browser js development so I leave it to jQuery to do that for me. jQuery allows me to use js in a powerful way, easily and quickly.

It's disappointing to not see jQuery in that list as if to say it's any less well made than the others.

No jquery?

It's disappointing they omitted jquery [jquery.com]. I've been using prototype + scriptaculous for a year and a half, but after a friend's recommendation, I took a look at jquery. I decided to try it for a day as I start the rewrite of mogopop [mogopop.com]'s authoring tool, and now I'm now comitted to using it for the entire rewrite and all future projects.

jquery's killer features are its selector syntax and Chainability [jquery.com]. From the tutorial, I can say "to all 'a' tags, add the 'test' class and show them" with $("a").addClass("test").show(). Or just the 'a' with id 'bar' with $('a#bar'), or just 'a' with class 'baz' with $('a.baz'). It's simple and concise, and perfect for most of today's ajax uses.

With its Ruby like syntax and solid plugin architecture, it's sad it follows the Rails philosophy more than the Rails spinoff Prototype.

Prototype Screencast

I recently released a paid screencast on Prototype together with one of the core developers. The screencast and a short preview can be seen here:

http://peepcode.com/products/javascript-with-proto typejs [peepcode.com]

Why just AJAX?

I've been looking into web frameworks lately, a lot of different ones (Java, Perl, Python, Ruby based ones). I finally decided upon going the Ruby-on-Rails, and probably the Ruby ActiveScaffold [activescaffold.com] plugin.

One of the things that turns me off about frameworks in general, is the almost maniacal focusing upon AJAX. AJAX can do a lot of things nicely (Google Earth as the classic example), but for most web sites, all it does is add a slight bit more interactivity to forms. And many of the frameworks I looked at, handled forms nicely, but if JavaScript was turned off or unavaialble (like on some PDA's, Phones, and other environments), they were unusable.

I became very intruiged by Hobo [hobocentral.net] as a Ruby on Rails plugin. Unfortunately, all the (scant) examples are so AJAX-centric, and do not degrade gracefully at all without JavaScript, I have no idea if it can be used effectively in a non AJAX environment. (I could spend a week exploring this, but I'm just going to move on with a framework I know will work.) A damn shame, because Hobo has a lot to offer.

I believe I am finally settling on ActiveScaffold, because it seems to degrade very nicely in the absence of JavaScript, and doesn't seem so heavily dependant upon it. Seems to have a good community around it, and isn't too heavyweight.

(BTW: Many of the Ruby plugins actually use prototype [and scriptalicious, I believe]; in fact, Prototype libraries come as part of Ruby on Rails.)

What about Microsoft?

Why isn't Microsoft's AJAX.NET [asp.net] reviewed? I figured they would be a major player in this, right?

This is not a review

I think people are getting confused by the /. blurb. This article is not a review, it is a case study. This company is describing the process that it went through months ago in determining which software to use. That's why some of the versions are out of date. That's why they quickly discounted software packages that didn't work with their existing infrastructure. If you read the very first paragraph it tells you that they had very specific design constraints and that's why some packages weren't evaluated fully. You simply don't have that in a review.

A case study is supposed to give an overview of the decision making process and the implementation phases of the project. And that's exactly what this does. They goal was never to produce a document that gave an objective evaluation of the products, it was to show the decision making process they went through in their evaluation. No where does the Dr. Dobb's site call this a review.

DWR

The name of the software is Direct Web Remoting [getahead.org]

How can we take this seriously if they don't know the name of the software they are evaluating?

DWR = Direct Web REMOTING

WTF - this article might as well have been written last summer. DWR version 2.0 is now out and has been in beta for a while.

The 'R' in DWR does not stand for for Reporting, but rather "Remoting". Both TFA and the ./ post are incorrect.

Not really out-of-date...

If you check the first page of the article, you'll notice it says that the project started in 2006 (who knows as to exactly when) and went production mid-December of the same year. So, there wouldn't be anything new (released 2007) in the first place.

Lets get hypothetical for a moment, and look at when the frameworks' versions noted in the article were released (these are estimates based upon announcements, datetime stamps, etc)...

Dojo 0.3.1 released ~06/12/2006
Prototype/Scriptaculous 1.4 - probably Prototype version, I'd say Scriptaculous is either 1.5 or 1.6 release ~3/2006 - 4/2006
DWR 1.0 released ~8/29/2005
YUI 0.11.1 released ~07/17/2006
GWT 1.0 released ~05/25/2006

If we take the most recent release date (07/17/2006) as the start date of their project and they took about a month (~8/17/2006) to evaluate the frameworks, the versions available by 8/17/2006 are...

Dojo 0.3.1 released ~06/12/2006
Scriptaculous 1.6.2 release ~8/15/2006
DWR 1.1.3 released ~7/11/2006
YUI 0.11.2 released ~07/24/2006
GWT 1.1 RC1 released ~08/9/2006

Comparing what would have been available based upon the "guessed" start date of the project, there really isn't anything new or overtly glaring. Except maybe for DWR.

So people, when reading this article don't think of it as a review of what is available now but rather a case study/retrospective/white paper of what they did.

Ajax security

http://www.cgisecurity.com/ajax/ [cgisecurity.com]

Anything but Yahoo UI!

I have had to butt heads with YUI on more than one occasion while working on Gallery2 (a php photo gallery system). It is evil in the worst ways. Often I will give up after chasing functionality through a dozen function calls and still be nowhere near the code that I need to find to decipher the undesirable behavior in question. I admit, opening a popup element with open_popup(x,y,source) might be a bit too much to ask, but when I get literally *TWELVE* levels deep in the function call list and still haven't found a single bit of code that actually DOES anything to the page, there is something wrong.

Anyone used Adobe's Spry framework?

Spry [adobe.com] is still in pre-release but up to version 1.5 and looks to be getting pretty good too. It's also fully open source under a BSD license.

We're currently looking at a few AJAX options at work too so I'd appreciate any feedback from anyone who's evaluated it particularly against jQuery and the others in TFA.

RichFaces and Ajax4JSF

If they were serious about sticking to the Java way of doing it and using WAS why didn't they look at RichFaces and AJAX4JSF? These companion project are very mature and offer a fantastic way of getting AJAX into your Java web apps.

They work even better if you combine them with JBoss Seam.

This isn't much of a "review"

If you actually read the article, its a pretty sad excuse for a review. Of the 5 frameworks, 2 of them are dismissed immediately because they didn't meet the exact coding styles of their development team for this specific project.

The other 3 aren't really reviewed either, except to describe how well or poorly they matched up with how the author's development team already developed code for their projects. This article is more of a story about one development team's choices during their process of developing a new site for their company than it is a review.

yeah, you're the only one

Better be careful about bloating your page by 10s to 100s of KB. Oh God, why haven't you provided unto us some sort of fast, readily available internet access !?!?!?! Perhaps through the same system that delivers our cable television content? What an idea, venture capital here I come! Frameworks are good. Don't use the crappy ones and you'll be fine. Dojo, for example, you can feed and parse JSON from and just pick and choose the bits you like. I use it with Struts2.

AJAX frameworks are NOT pointless

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 [microsoft.com]:

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 [outofhanwell.com], 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 [bazon.net]
MSDN's lengthy and confusing description of the problem [microsoft.com]


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 [apple.com] and hack away, right?

Why not do 6

Why would they leave out asp.net ajax?

Dont you dare pass over JSDC 1.3!

Especially since it is my pet project.

JSDC, Javascript Data Components(http://jsdc.sourceforge.net/docs_refere nce.php) has some really interesting stuff.

I'd say it's somewhere in between a library and a framework..It doesn't force you into anything.

It features:
* Client-side datasets with nested transactions(or maybe it is more of an undo history), master-detail.
* Input verification
* Treeviews, Table views and other stuff
* A quite interesting non-blocking animation class.
* And more.

Check it out!

jQuery

I've found jQuery to be very easy to use, especially for simple stuff. I was up and running with jQuery in about 30 minutes, though I had to implement some UI logic myself-- with Dojo that was already built, but it didn't do what I wanted, so I spent a while struggling with it before giving up.

jquery -- http://www.jquery.com/ [jquery.com]

It's interesting, it basically just does two main things well: 1. provides a nifty function for getting a handle on a DOM element using either XPATH or CSS selector syntax, fairly painless once you figure out the selector/path syntax, and 2. has some functions for sending JSON or XML requests to the server and getting the response sent to a callback function (that's the AJAX part).

Unbloated Javascript library

Some posts here have mentioned the large size of most javascript libraries.. I personally had the same problems and wrote myself a minimal javascript library with only:

• HttpRequest related functions
• IE compatibility layer for style classes and events
• a DOM builder
• firebug simulation
• a few helper functions

The whole thing is about 8kb for the js-compressed version (about 4kb if you also serve it gzipped) and is available under a BSD-like license from my blog site [fforw.de]