javascript ant

This looks like a good breakdown. The only downfall is that each library really approaches things differently so it’s hard to just look at this and say, “X library is better”. I suspect that’s not what you’re trying to accomplish with this table but I fear that’s what people will take away from it. Otherwise, well done on the research. :)

Hey Jonathan,

Thanks for the feedback. We are definitely on the same page. There are a lot of concerns with releasing this comparison, and our hope is that developers use it responsibly as an aide to choosing the right tool for the right job. Only time will tell :)

Prototype has public unit tests. They live in our SVN repository. Also, regarding “Official widgets/UI toolkit”: script.aculo.us is just as “official” as, for instance, jQuery UI. They’re separate projects, but tightly affiliated and with coordinated release schedules.

jQuery uses google groups – I’d expect that to give it a tick against forum (row 17) as you can view and post comments/topics via the browser, search for posts, etc.

Nice work. I agree with Jonathan’s comment above. On the topic, I recently wrote an article on why I choose Mootools vs. other frameworks, and most of the points I make about it have nothing to do with the data in this table. That’s not to say that this data isn’t helpful, but rather that the decision has much more to do with style, (code) philosophy and other subjective things (I also say none of these frameworks make a bad choice; they’re all excellent).

FYI, Mootools 1.2 (due out very, very soon) has included unit tests in the code base, included documentation in the code base, and I’m personally in the process of writing the first book, due out on Apress in a few months.

This is silly. Not a single comparison item is usefull. What people need to know is what features/functionality is provided, not these obscure side issues.

Any reason that Tibco’s GI isn’t included in the list – I understand it’s BSD/Apache?

Hi Vidal,

That is actually on our immedate to-do list for the comparison. We will be analyzing features that designers/developers desire like animations, AJAX implementations, etc. The trick is coming up with commonalities that make sense. Thanks for the feedback.

@Vidal – Thanks for the comment. However in a kind manner I would like to suggest to you that the table is incredible useful from certain perspectives. For example, this table can quickly help organizations (decision makers) make informed decisions before banking on the use of one of these libraries. This is just a starting point.

From the perspective of a developer, looking for code comparisons, the table obviously falls short. But, again this is not what the table is trying to communicate.

The table is a high level overview of the libraries and the factors that an organization (or development team) might want to consider before using one of the libraries.

I hope that from this perspective you might see some value in the table.

(surfed on in from dzone)

The breaker for me with most, if not all, JS kits is the total lack of Section-508 compliance. As a government contractor, this requirement has proven as a huge barrier to moving my work on the job toward a web 2.0 style experience.

The other features are nice, don’t get me wrong, but without 508, there’s almost no point.

Nice breakdown, should be useful.

Comment about the table though, I imagine it’d be easier to read quickly if you only used the ticks and not the crosses, at the moment it looks like a huge wall of red and green and it’s a bit overwhelming.

Just some more info about DOMAssistant:

Official hosted minified version:
There is a version offered through cachefile.net

SVN/CVS access is available at the Google code site

Official Mailing list: you can sign up for e-mail updates

@Pragma: Great point on the lack of attention for accessibility. However, it’s up to the developer to implement progressive enhancement, and maintain accessible content and behavior, and it is possible with some of these JS libraries. For example, with jQuery, the AJAX behavior re-uses the “normal” server calls (such as action in a form)—it’s building on top of the regular behavior. This way, if JS is not available, the default functionality still works.