Love the web

Love the web is a design, programming, and usability blog

Choosing a JavaScript framework - will it fly? 3 comments

Peter Dekkers 12 Mar 2009

Alexander Graham Bell's giant ring kite
Alexander Graham Bell's giant ring kite - it flew!

Over the last few years at Springload we've employed a number of different JavaScript libraries and frameworks: DOMAssistant, Prototype and script.aculo.us, MooTools, YUI, jQuery. We even spent some time writing our own framework. Some of these were decent and quite good to use while others presented us with more challenging experiences. However we never seemed to naturally settle on one. So we decided to take a step back and do a full assessment of the options because we felt choosing a single framework made a lot of sense.  The most important benefits that we were looking for were:

  • Code consistency across projects
  • A robust framework
  • Transparent handling of common browser inconsistencies
  • Speed when doing CSS/DOM selections
  • An easy-to-read and elegant syntax
  • Methods for basic animations
  • Not too much superfluous functionality in the core framework
  • Making our code readable for the largest number of staff possible
  • Small file size
  • Good backwards compatibility
  • Good futureproofing
  • Namespacing
  • Good documentation

Let's run through these in order and see which choices we made and why.

Code consistency across projects

This is pretty logical and doesn't really come down to which framework you use, but rather what sort of standards you employ. We found that in the syntax department the only framework that really stands out is jQuery. The reason being is that all other frameworks use a standard JavaScript syntax while jQuery did a bold move and invented their own. YUI for example has a strict JavaScript syntax and is also very verbose. Some people are fans of this as it is true to the nature of Javascript. jQuery's syntax is concise and hides a lot of the coding fluff that you usually end up writing and as you write less code it is easier to keep it consistent.

A robust framework

Most of the current JavaScript frameworks are pretty robust. There are a few small exceptions. Prototype's DOM selector methods are a little flaky at times but robustness is something that all the libraries strive towards. Most frameworks also have test suites. jQuery has a unit testing suite called QUnit and you can run their unit tests in your browser on their site. YUI also have a unit testing suite so do Prototype and Mootools. These tests breed confidence. A benefit of YUI is that it's being developed commercially by a large organisation, "YAHOO!".

Transparent handling of common browser inconsistencies

Not having to write the same workarounds or repeat yourself each time is what any framework should be about. This is one of the mainstays of most frameworks and they are all pretty good at it. The folks at YUI and jQuery - from my knowledge - do some really rigorous testing. John Resig - the creator of jQuery's - did a talk for Yahoo! titled "The DOM Is a Mess". It provides some great insights into jQuery's testing processes and handling of browser incompatibilities.

Speed when doing CSS/DOM selections

You usually end up doing a lot of selections especially when writing unobtrusive JavaScript. A great way to gauge the speed of the different frameworks is by using the SlickSpeed test. You can download the test from Google Code and run your own choice of frameworks against it. Even if a framework isn't the ultimate speed demon you can still use this test to get a good overview of which selectors it's good or bad at and adjust your code accordingly.

An easy-to-read and elegant syntax

We covered this in the "consistency" paragraph. So let's look at an example of some classic vanilla JS and the same code in jQuery. Here we are removing a row from a table. The rows have alternating colours, and so after removing the row, we have to re-colour the alternating rows.

Plain vanilla JavaScript:

var row = document.getElementById("row_id"); // If we have a valid row node if(row){ // Get TBODY node var tbody = row; while(tbody.tagName != "TBODY" && tbody.tagName != "BODY"){ tbody = tbody.parentNode; } // Get TABLE node var table = tbody; while(table.tagName != "TABLE" && table.tagName != "BODY"){ table = table.parentNode; } // If we have valid TBODY and TABLE node if(tbody.tagName == "TBODY" && table.tagName == "TABLE"){ // Remove the row table.deleteRow(row.rowIndex); // Loop all remaining rows var row_class; var rows = tbody.getElementsByTagName("TR"); // Remove the "stripe" class for(i=0; i<rows.length; i++){ row = rows[i]; row_class = row.className; row.className = row_class.replace(/stripe/,""); // Add the "stripe" class if it's an even row if(row.rowIndex%2 == false){ row.className += " stripe"; } } } }

And now the same in jQuery:

// Get TBODY node var tbody = $("#row_id").parent("tbody"); // If we have a valid TBODY node if(tbody.size()){ // Remove the row $("#row_id").remove(); // Remove stripe class and add it again to even rows tbody.find("tr").removeClass("stripe").end() .find("tr:even").addClass("stripe"); }

The obvious benefits of the latter are more concise code and less need for checking if a node exists before working with it.

Methods for basic animations

Again this a a mainstay of most frameworks. The exception is DOMAssistant which is a framework that prides itself on being lightweight and doing mostly DOM selections. It doesn't do animations.

Not too much superfluous functionality in the core framework

A framework should really be a solid core that you build your application-specific functionality on top of.  Its functionality should be reasonably abstract and high-level. Again most frameworks are quite good at this and a few provide many additional features through extra "plug-ins" most notably YUI and jQuery. A point to note is that jQuery plug-ins aren't always very reliable because they are being developed and tested by a large group of independent people, whereas YUI's plug-ins are developed and tested by the same team that develops the core framework.

Making our code readable for the largest number of staff possible

We have a number of integrators whose specialty is CSS. However when building a site template in CSS they usually need to make navigations work in certain ways or to provide slides that transition between one another. These things are written in Javascript so if we can make that JavaScript easy for the integrator to understands and adjust it’s a great bonus and means more time to do work and less time sending pages back and forth. Again this is a feature that we only really found in jQuery: after reading the short intro on the jQuery site its syntax was almost immediately legible to integrators.

Small file size

This is always important, as we want to cater for people on any sort of connection. DOMAssistant was a clear winner here, but its functionality is limited to the very core which means no animations. YUI's core also scored well but you'd need to load some more files if you want animation or even Ajax, and personally I would rather load one larger file than two or three separate smaller files. Of course you can manually combine YUI files into one file but the YUI Loader Utility seems to suggest otherwise2. So with DOMAssistant being out of the question as it doesn't cover enough bases and YUI loading many separate files - and that being evil - we're down to the remaining libraries which all sit around the same filesize: about the size of a medium JPEG image1.

Good backwards compatibility

Of utmost importance is the ability to seamlessly upgrade your framework to the latest version without running into problems. Prototype proved especially bad at this, we updated a site from 1.4 to 1.6 and it broke a bunch of "getElementsByClassName" calls. The other frameworks seem to work okay. It's hard to tell without reading exact policies written by the framework creators as to how they will handle this issue in the future. I have a bit of a question mark here as all I am going on is previous track record. jQuery seems to support all old methods which is a great start.  It does mark some as deprecated but none the less supports them.

Good futureproofing

When a major new browser gets released we want the framework to be ready. YUI, DOMAssistant, Mootools and jQuery seem to be up with the play and provide compatibility with future browsers such as Internet Explorer 8. As far as I could see Prototype doesn't seem to provide any compatibility information. Support of new technologies like CSS3 is also important to consider. YUI's Selector Utility adds CSS3 support but is currently still in beta. All the other libraries seem to fully support CSS3 selectors.

Namespacing

YAHOO has strict name spacing for all its core methods. While this adds robustness it also makes the code you write more verbose. At the same time namespacing in any code is still possible by using regular JavaScript namespacing. A bonus of jQuery is that even though it doesn't namespace its core methods you can still use it in "compatibility mode" with other frameworks. For example Prototype and jQuery both create a core method called "$". When you use jQuery in compatiblity mode the core method "$" isn't available and instead it'll be called "jQuery". This is great news for cases where you have to include both frameworks.

Good documentation

DOMAssistant has great documentation. So dose Prototype, Mootools and jQuery. YUI's documentation - while complete - seems to be in many different places. There's no one-stop-shop that gives you all of the YUI documentation. This makes it hard to mainta the documentation of the code you are creating. A problem I was keen to keep away from!

jQuery excelled here it provides documentation online and also offline as a cool Adobe Air app. It lets you search the methods and even executes the JavaScript right inside the app. Maybe it's not necessarily better but at the very least it's innovative.

Conclusion

I'm sure you can tell that we ended up choosing jQuery. YUI came a close second but  jQuery syntax was simply clearer to less experienced programmers than the YUI syntax. After a few months of using jQuery I have been pleasantly surprised by how good it is. Integrators have been writing functional navigations without any programmer's assistance and I've seen our code shrink enormously, usually to about half the size.

Many of the issues raised in this article are open to a great deal of discussion so if you have any comments, please post them!

Footnotes

  1. It's been noted that the filesize is less relevant when you Gzip text files before sending them to the browser. Gzipping should be active in most professional hosting environments and will reduce the size of most frameworks to a fraction of that "medium size JPEG file".
  2. YUI offer some interesting insight into the benefits of reducing HTTP requests in an article on their blog. They also provide rolled-up or combined files, but in my opinion not often enough. There's a page dedicated to hosting YUI files directly off of the YAHOO! servers. Via this page they let you automatically combine the files you need into one file. However if you wish to serve up your own YUI files you will have to combine them yourself. It's fair to note that serving the files from the YAHOO! servers could provide additional speed benefits as their network provides high-end hosting and mirroring.

Read the next post - Power editing with Textmate

Subscribe to these comments

3 comments submit a comment

07 Oct 2009

Simone

What a great comparison. We've been thinking about this ourselves and your discussion was very timely for me. Thanks.

10 Nov 2011

thorpe

You should checkout backbone.js (http://documentcloud.github.com/backbone/) as a companion to jQuery.

It really makes code organisation and reuse easy.

11 Nov 2011

Peter Dekkers

Thanks for the recommendation Thorpe, looks fantastic.

Submit a comment

Do not fill in this field (bot protection)

Submit comment

Love the web posts

Code

Design

General

Usability