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.

Comments

Nice, printer format...

[jbarr]

http://ww6.infoworld.com/products/print_friendly.j sp?link=/article/06/07/31/31FEajax_1.html

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

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

Re:"Open source?"

[achacha]

The only reason large corporations push some toolkit as "open source" is because:

1. It's a crappy product that their marketing people cannot justify as promotion cost
2. There are better free products
3. They are trying to get their foot into the niche so they can then charge for the "Professional" version
4. They don't understand the space yet

This is common for Microsoft and now becoming common for Google.

Sadly AJAX is still the "silver bullet" of web based companies and the buzzword of the moment. So many companies are using AJAX for the sake of using it despite the fact it is not applicable to the ir use case; sometimes it is easier to wedge something in and use a buzzword to sound cool and relevant.

Re:"Open source?"

[Anonymous Conrad]

Last I checked, neither Atlas nor GWT were open source in any sense of the word,

But you can download the Atlas source code and at first glance the licence meets the Open Source definition: it's a simple no endorsement, no liability, no patent disputes licence. So what's the problem?

Re:"Open source?"

[hey!]

5. Because they can't allow a hostile competitor to obtain control over a piece of software infrastructure that is critical to them.

i.e., they have learned the lesson of Borland.

e.g., Oracle can't survive in the long term if Microsoft gains control over server platforms

e.g., IBM can't survive inthe long term if they have to use Microft's own tools to complete with it.

So: yes, support of open source is self interested in cases like these. But not necessarily cynical or pernicious.

Java != Javascript

[andrewman327]

From TFA: "[...] JavaScript is pretty close to a superset of Java[...]. It's not complicated to strip away some typing information from the Java code and end up with something that resembles JavaScript."

This is in response to Google's toolkit, which allows users to code in Java instead of Javascript. I think this feature is a real winner to Java coders. Who wants to code Javascript when you can use Swing? Regardless of what TFA says, there is a difference between the two programming experiences.

In summary, if you are already proficient in Java, Google is the way to go.

Re:Java != Javascript

[StarvingSE]

The author of TFA is just dumb and doesn't know what he is talking about. First he says that Microsoft Atlas is open source. Then, it sounds like he truly believes that Java and Javascript are related in some way. Besides some similar syntax, they are both mutually exclusive.

when are people going to realize that Javascript and Java share only a name???

Re:Java != Javascript

[Anonymous Coward]

Who wants to code Javascript when you can use Swing?

Google did not write a Swing API for JavaScript. That would be incredibly complicated and not worth their time. As you can see here, only some classes in the java.util and java.lang packages are supported, and some of them do not have identical APIs due to the differences between Java and JavaScript. The user interface can be written using GWT's components.

Re:Java != Javascript

[andrewman327]

The confusion of Java and Javascript is one of my biggest pet peeves in computer science. I am fairly proficient in Java, but I still have to look up which command to use the once a year I actually write in Javascript. Google's engineers worked hard to design a system to convert Java into another format only to have this journalist completely disregard it.

It's times like these that I am glad I get to tag articles.

Re:Java != Javascript

[Selanit]

An early development version of JavaScript was code-named "mocha." All the way through the old 4.x series of Netscape Navigator, you could access the JavaScript console by typing "mocha:" in the address bar. How I wish they had just adopted that name for the language as a whole! It would have prevented so much confusion.

Re:Java != Javascript

[larry bagina]

Mocha was renamed to LiveScript, which was then renamed to JavaScript (and later ECMAScript). "JavaScript" is actually a Sun registered trademark. When JS first made it's oh-so-buggy appearance, I thought Netscrape was trying to jump on the Java hype, but I think Sun paid them to change the name.

Re:Java != Javascript

[SanityInAnarchy]

I'm just the opposite. Java is just a bastardized C++, which is a beyond-bastardized C. JavaScript is a real language -- it's a bit like Ruby, kind of a Lisp in C's clothing.

Re:Java != Javascript

[stu42j]

The history of JavaScript from its inventor:

http://wp.netscape.com/comprod/columns/techvision/ innovators_be.html

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

[LiquidCoooled]

and for all other effects write your own functions just like always (copy/paste from your personal library and adapt)

Or you just do exactly what digg does and take your own javascript library and include everything you possibly can do "just in case".
I'm actually surprised kitchenSink.js isn't included.

This is just an example from the standard front screen of digg without any cookies or logins to concern itself with.

  <script src="/js/spellChecker.js" type="text/javascript"></script>
  <script src="/js/utils.js" type="text/javascript"></script>
  <script src="/js/xmlhttp.js" type="text/javascript"></script>
  <script src="/js/comments.js" type="text/javascript"></script>
  <script src="/js/wz_dragdrop.js" type="text/javascript"></script>

  <script src="/js/hover.js" type="text/javascript"></script>
  <script src="/js/label.js" type="text/javascript"></script>
  <script src="/js/dom-drag.js" type="text/javascript"></script>
  <script src="/js/switcher.js" type="text/javascript"></script>
  <script src="/js/prototype.js" type="text/javascript"></script>
  <script src="/js/scriptaculous.js" type="text/javascript"></script>

  <script src="/js/lightbox.js" type="text/javascript"></script>
  <script src="/js/aboutdigg.js" type="text/javascript"></script>

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?

Re:Erm...

[tenchiken]

As someone who has tried to do what you suggest, and then worked in pain to deal with all of the cross browser issues, the strange XMLHttpRequest behavior, systems for relability,etc, the bloat is well worth it.

Re:Erm...

[ukleafer]

dig into the framework and basically "make it their own".

just an aside, but any modification of the framework code itself in GWT (maybe some of the others too?) is a breach of the T&C that the developer accepted before downloading the kit.

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.

Re:Erm...

[Bogtha]

Nice to see that they forgot that the MIME type for JavaScript is "application/javascript"...

Forgot? The media types for JavaScript were only standardised this year. Before April, application/javascript was merely a common convention - and actually a less common convention than text/javascript, which is also an acceptable (if deprecated) media type for JavaScript according to the RFC.

So a) there wasn't anything to "forget", and b) they aren't doing anything wrong anyway.

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.

DWR

[kevin_conaway]

If you're doing Java/J2EE work, you should really have a look at DWR

It makes it disgustingly simple to expose pretty much anything as AJAX calls

Huh?

[LaughingCoder]

... support of one or more stable organizations.

Why do we care what horse-breeders think? I mean since when have they been the technical thought-leaders?

Spelling mistake in Summary

[HugePedlar]

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

Hemos appears to have misspelt "incorrect" as "broad".

I've just implemented my first AJAX site...

[Toreo asesino]

Using Atlas for asp.net (http://atlas.asp.net/). Fantastic framework; unbelievably simple.

I took a normal asp.net form I built for an ordering-page (lot's of postbacks for updating various basket options, etc, etc), wrapped it in an atlas XML container (all of 10 seconds work), and Bob became my uncle - the entire thing was AJAX enabled, doing lightweight postbacks & updates instead instead of the usual full-page postbacks you normally get with asp.net page-events.

And all the JS is cross-platform too - IE, FF, Safari, etc (allthough, sadly, no Opera support just yet).

And the best thing is, for all you JavaScript haters is turning off JS in the browser just meant the page automatically reverted to full-blown postbacks instead; thus not limiting accesibility.

Oh, and I understand you can link php into Atlas too, but I'm guessing there's other stuff out there for php aswell.

A better review (w/ actual code samples)

[jbellis]

http://www.sitepoint.com/article/javascript-librar y

--
Carnage Blender : Meet interesting people. Kill them.

Re:A better review (w/ actual code samples)

[wranlon]

I've always liked my own AJAX framework, Engine for Web Applications, but it never seems to make it farther than the appendices (if even) - here are some good toolkits, see appendix A for some other stuff that showed up in Google.

Just did this myself

[slindseyusa]

I just went through and evaluated most of these myself in the past week because of a new work project. Dojo is by far the best when looking at building a real web "application". The others have limitations (such as Google's toolkit which requires you to write your code in Java) or are focused too much on "flashy" stuff. Dojo provides dialog boxes, windows, an editor, and more. It still has bugs and is an early version, so you need to consider your audience and time frame. For example, I had a problem with FF 1.0.7 (even though they say it is supported) but I only need to support FF 1.5 and Safari 2. I'm building a complex web app for an internal audience and I can guarantee they'll have one of these 2 browsers. Still, it seems to have broader support than some of the others toolkits. While I'm jsut starting with it, I've been happy so far. There's little documentation but the examples are good enough to get you started.

Echo2 is good!

[Anonymous Coward]

What about Echo2 http://www.nextapp.com/platform/echo2/echo/ ?

script.aculo.us?

[LFS.Morpheus]

Why is that script.aculo.us is left out of these comparisons? script.aculo.us is behind the AJAX in most Ruby on Rails apps, but it can be used on its own. (As of Rails 1.1, Rails has special built-in support to make it even easier to use.)

Re:script.aculo.us?

[bigdadro]

Probably because scriptaculous is an effects library built on top of prototype, without prototype it is useless.

Re:script.aculo.us?

[LFS.Morpheus]

It's not just an effect library (anymore?). Yes, it is built on top of prototype - in fact, scriptaculous has the only documentation I know of for Prototype. 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.

If you're interested in JS toolkits... (Dojo, etc)

[ChrisZermatt]

...make sure you check out qooxdoo.

Its not the best known, but its one of the most promising toolkits in [very] active development. I've been involved (sort of -- following the mailing list) and its open source & very slick.

http://www.qooxdoo.org//

The 0.6 release is expected in the next day or so, and is a big jump over 0.5. The only area that is still a bit weak is the documentation, but there is a good group of developers working actively on getting that properly sorted for the next release.

Should have reviewed DWR

[bryanbrunton]

As many have noted the article is really quite clueless. However, any review on Ajax toolkits is not complete with a mention of Direct Web Remoting.

Central idea behind DWR is it exposes methods of Java Beans over the web. Create a server side class and then call methods from javascript like this: MyBean.method(). It couldn't be simpler.

I have used DWR in my just released online version of Risk, called Grand Strategy.

Erm... what about?

[Anonymous Coward]

I'm a little surprised that nobody has mentioned jQuery (http://jquery.com/). While it does AJAX, its much more than that, and lets you write some seriously concise script. There's also a lot of activity from Dean Edwards (http://dean.edwards.name/) on the mailing list, which is probably a good thing. Also looks like it might be the only/first library to find a true solution to the whole cross-browser "window.onload" problem (as of version 1.0, currently in beta).

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/) library with niftycube (http://www.html.it/articoli/niftycube/) 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

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.

Yahoo YUI Toolkit

[DeionXxX]

Personally I think the Yahoo YUI Toolkit is the best framework out there. It is commented very well, it is 100% cross browser compatible (they test on Opera, Firefox, Netscape, IE etc). It is fully supported by a team of engineers. They provide several versions of each script, so you can build your site with the -debug script, move to the normal script, and then when putting it on a live server, you include the minimzed script which is much smaller.

My Own Survey

[2Wrongs]

Just my experience, but they were all a little lacking (although I admit I'm a novice in AJAX).

Rico's newsgroup was great; I got (friendly) answers within hours, but I'm not exaggerating when I say the documentation was the worst I've ever seen. If I had more time to play around, I would have stuck it out and helped (their community is cool), but I'm on the clock and need simple working examples.

I briefly tried Atlas and was impressed with ease of use, but got hung up with bugs (it's beta, but will be a good tool when it's ready).

Dojo had good starter documentation. I spent a while trying to figure out something poorly documented and figured I'd write a brief tutorial, but was surpirsed they have a "closed" Wiki. After some digging, it suggested dropping the developers a line to get an account, but wasn't able to find the address. I gave up. I can see why their documentation is so spotty, since they ignore what a great tool a Wiki could be. The psuedo-Wiki gaps are somewhat filled by a pretty good newsgroup though.

YMMV, but Dojo was the best of the tools I worked with.

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 has some pretty good documentation. 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 docs 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:Documentation

[MConlon]

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.

Dojo's widgets can be defined using a separate namespace, "dojo", so your XHTML will validate. As in: <button dojo:type="Button" dojo:widgetId="helloButton">Hello World!</button>

MJC

Qooxdoo

[valamaldoran]

I've tried Dojo and the Prototype derivatives - Moofx, Rico and Scriptaculous. I don't really like Dojo because it seems so basic. Moofx is pretty good for lightweight effects, and the weight factor for effects goes up with Rico and even more with Scriptaculous. Bad thing about Prototype based scripts is that it doesn't play well with others due to Prototype's large manipulation of core objects. Enter QOOXDOO. Qooxdoo surprised me with how advanced it was. And its free. It is definately the script anyone needs to build a complex user interface for any application, because its designed to look just like an application. Its documentation is sparse, but the development community is amazing. they respond very quickly, and are working hard to fill the gaps on the documentation. The latest version is a vast improvement. The examples are very diverse, showing all the possibilities this remarkable script can do. if you really want to see an advanced framework that looks incredibly awesome, check out Qooxdoo...http://www.qooxdoo.org

W3C Standard-based ones

[leighklotz]

There are also toolkits and JavaScript apps that combine W3C standards with AJAX, letting you write a lot of the dynamic page stuff in a declarative fashion, using just markup (XHTML+XForms; I was an editor of the XForms 1.0 recommendation, but new revisions have come out; see http://www.w3.org/TR/xforms).

The FormFaces OSS product is an entire XForms implementation done in JavaScript, running in the browser. You write your page in HTML with XForms markup, and FormFaces does the "HiJax" thing of re-writing it for you. You never need to use XmlHttpRequest, and you can interact with regular servers, RESTful services, etc., all via XML.

Another product that does this, in a slightly different way, is AjaxForms. I just found out about it, but it looks pretty good. AjaxForms uses some server-side components to do the translation from strict XHTML+XForms markup into Ajax (HTML4+JavaScript), but they claim it can work in PHP and Tomcat servers. Again, FOSS, and available at http://ajaxforms.sourceforge.net/ [sourceforge.net]

I recently implemented dynamic forms for weblogs and wikis, and did it using Chiba, another FOSS product, that like AjaxForms does its conversion on the server, using Tomcat as a container.

The Orbeon folks have a nice blog that shows how to use XForms (their implementation, the Mozilla extension, or any of the other above toolkits) to accomplish typical dynamic page tasks such as listing countries and ISO codes, or resizing flickr (also via formsplayer.

Php & js Ajax toolkit & Visual development

[zeemu]

APhPLIX is a toolkit for building Ajax web applications with a traditional GUI.
It comes with a visual development studio web application for point and click application development, and it's all open source.

I think there may be some similar proprietary products, but I don't think there are any other open source projects like it.
--
zeemu