Open Source AJAX toolkits

twofish writes "InfoWorld columnist Peter Wayner recently reviewed six of the most popular "open source" Ajax toolkits. The article sets out to see if they are enterprise ready in comparison to commercial products such Backbase, JackBe, and Tibco's General Interface. The six open source projects covered were selected because each has a high-profile in the developer community and support of one or more stable organizations. "

The toolkits covered are:

1. Dojo
2. Google Web Toolkit
3. Microsoft Atlas
4. Open Rico and Prototype
5. Yahoo AJAX Library
6. Zimbra Kabuki AJAX Toolkit

Whilst the definition of open source is broad, the round-up is quite helpful.

"Open source?"

[cbiffle]

This column uses an interesting definition of Open Source.

From the article:
Microsoft's Atlas may not be open source -- the license includes terms that would rankle a devotee -- but the code you create with the system is yours to license as you like, and you'll be able to create Atlas apps with few practical restrictions.

Oh. Is that what Open Source means? That I can create apps with it and license them how I like? Well, crap, Visual Studio must be open source too!

Last I checked, neither Atlas nor GWT were open source in any sense of the word, though at least GWT will run on real servers.

Erm...

[savala]

If you want to add AJAX to the magic collection of buzzwords supported by your Web site (and who can resist the siren call of the latest buzzword?), then you have two major options: purchase a proprietary package or experiment with open source libraries.

Or just write the ten lines needed to do XMLHttpRequest calls yourself (there, that's the AJAX part taken care of), and for all other effects write your own functions just like always (copy/paste from your personal library and adapt), so you don't have to deal with bloat, nine out of every ten functions being unneeded, and far too many levels of abstraction and generalization, and have the benefit of actually being able to quickly debug the script when you encounter a problem!

The only organizations where these toolkits might be useful are the really really large ones where there's a team that can dig into the framework and basically "make it their own". Everything smaller, using occasional contractors to maintain the code, benefit far and far more from simplicity, readability and maintainability than from dubious-quality top-heavy frameworks with lack of code-level documentation and thousand and one edgecase-bugs. (Spoken like someone who's had to trace such bugs in the mess of prototype and scriptaculo.us; I've only _looked_ at Dojo, Rico, Yahoo and Zimbra (and not at all at the other two), but my impressions were that what they made up in better code quality, they lost in bloat.)

Re:Erm...

[slindseyusa]

I used to agree with this, until I spent some more time looking into it. Certainly XMLHttpRequest is the most powerful aspect of Ajax and it is easy to use. But Ajax generally comprises much more than that. The Dynamic HTML part can get quite confusing, especially across browsers. Look at the examples of what some of these projects can do. They are certainly big and sometimes bloated. I'm still struggling with that part as well, but I don't have the time to figure out all the details when a toolkit can handle that for me. It's no different than using a high level language and libraries, or should I write all my code in Assembly?

Kudos to Rico

[klenwell]

I'd recently given myself a crash course in javascript for a site I was working on. Ended up using the moo.fx (http://moofx.mad4milk.net/ [mad4milk.net]) library with niftycube (http://www.html.it/articoli/niftycube/ [www.html.it]) for the all important rounded corners. Checked out dojo but it seemed a little more than I needed. Also glanced at Yahoo.

Looking over the packages listed here, I'm especially impressed with Rico. Single file used in conjunction with the prototype.js script. And a really excellent demo page:

http://openrico.org/rico/demos.page?demo=rico_effe ct_position [openrico.org]

The author of the article gives Yahoo credit for the package management -- I think Rico deserves a praise for their site, too. I look forward to giving it a whirl.

Re:script.aculo.us?

[LFS.Morpheus]

It's not just an effect library [aculo.us] (anymore?). Yes, it is built on top of prototype - in fact, scriptaculous has the only documentation I know of for Prototype [aculo.us]. But that shouldn't it exclude it from a list of AJAX library comparisons. That's like saying "well, the GIMP uses libpng so we're not going to review it amongst photo editors."

Anti-disclaimer: I don't have anything to do with the script.aculo.us guys, but as a Ruby on Rails developer it has served my needs just fine.

Re:Erm...

[saltydogdesign]

In my experience, prototype and Dojo are both very stable at this point, far more stable than would be any comparable library of my own making, as I don't have a team of developers or a large body of users available to test it for me. You think there's a thousand and one edgecase bugs in prototype? How many are in your personal library? I'd far rather rely on something that has been seen and used by a thousand people than something that's been seen and used by one.

As for the usefulness of these toolkits, weighing in at 53k (considerably less if you were to use any of the js compacting methods available out there), I find prototype to be an enormous time-saver, and the code saved in my applications goes a great distance toward offsetting the one-time 53k download for users of my websites.

Look, if I took your logic, the next time I wrote an OS X app, I'd write it from scratch in C, without the benefit of the Mac frameworks, and cut and paste from "my own personal library." And I'd probably want to compile it by hand too -- God knows what kind of code the compiler is actually generating, right?

There is a tremendous advantage to abstraction and generalization -- indeed, we'd still be coding ones and zeros if we didn't have it. Sure, you can take it too far too fast, but as one who has done a lot of coding with javascript since not long after its inception, I can tell you that unless you're not doing anything much more complicated than rollovers, it's time to move up. Whether you want to do that with community code or your personal collection is up to you, but I'd like to have a little free time at the end of the day.

Documentation

[Lord Ender]

I looked at some of these a while ago. Zimbra has one of the coolest demos. But many of these severely (or completely) lack documentation, which means they are not ready for anything but "mom's basement, no deadline" type projects.

This stuff is really exciting, but until there is documentation, it is not worth mentioning at work.

Re:Documentation

[Selanit]

Prototype [conio.net] has some pretty good documentation [sergiopereira.com]. Also, it's pretty low-level, so it's easy to build into other stuff. Heck, Prototype is worth it just for the each() iterator method!

Dojo's [dojotoolkit.org] docs [jot.com] are very much hit-or-miss. Some features are pretty smoothly documented. Others are like navigating a trackless wilderness with no more than the sun and stars to guide you. Also, Dojo's annoying because it requires you to add non-standard attributes to your HTML in order to identify widgets. For example:

<button dojoType="Button" widgetId="helloButton">Hello World!</button>

dojoType? widgetId? Those ain't gonna pass no validator THIS little programmer knows of.

Re:Erm...

[Bogtha]

It depends what you are using it for. For a complex DHTML interface for a web application that people use on a regular basis, sure, ~50KB isn't a big deal, especially when it's usually going to be coming from their cache. But for an average website that just wants to enhance particular aspects of their interface, it's ludicrous to make visitors download all that JavaScript, most of which will remain unused.

The Digg example LiquidCoooled posted is a good one. The Digg developers seem to have paid no attention to efficiency, they just dump everything they might ever possibly use onto every page regardless of whether they use one function or twenty. For instance, they reference a 36KB drag and drop library on every page on their site, but I don't see them actually using any drag and drop anywhere - do you? Or how about the fact that they reference aboutdigg.js on every page despite the fact that the code is only ever used on one specific page which most visitors aren't ever going to visit anyway?

Sure, there are a lot of instances where it's a good idea to use a library. But I think a lot of the people using libraries like this are doing so because they want to cut corners, not because it's the right tool for the job.

Re:Nice, printer format...

[jbarr]

Why is a comment which is just the link you get by clicking the printer icon on the original story worth +5 ??

Probably because a large percentage of the /. community prefers "to-the-point" links instead of the typical multi-page click versions. I personally get really annoyed by online articles that require page-click after page-click just to read an article, so printer-formatted versions typically are consolidated and easier to read. It was really just a courtesy that many in the /. community enjoy.

Was my post worth +5? Probably not, but obviously, enough appreciated it enough to mod it up....