Simon Willison’s Weblog

Notes on JavaScript Libraries

26th June 2006

@media 2006 was a blast. Great talks, great people and some of the highest production values I’ve ever seen at a conference (check out the bags!).

I sat on the JavaScript Libraries: Friend or Foe? panel, with PPK, Dan Webb, Stuart Langridge and Cameron Adams chairing. It was my first participation in a panel and I really enjoyed it—I’ve always liked the Q&A bit of giving talks. JavaScript Libraries are an enormous topic but I felt we did them justice considering the time available. For the record, here are the key points that I wanted to get across:

1. Large JavaScript applications need some kind of library—even if it’s one built especially for that application. There are a number of problems in JavaScript (most of them originating with browser incompatibilities) that any moderately complex application will need to deal with—things like normalised event handling, DOM node selection, sane animation or drag and drop. Solve these problems once so you can get on to the interesting task of building the application. If you can find a library that solves them for you so much the better!

2. The big four. Dojo, MochiKit, Prototype/Scriptaculous and the Yahoo! UI Library are the top of the pile as far as I’m concerned. They cover the bases effectively and each one offers something interesting that makes it worth studying in its own right. If you plan to evaluate some existing libraries these make an excellent starting point.

3. Leaky abstractions. Joel Spolsky’s essay The Law of Leaky Abstractions is my favourite of all of his online articles. It’s basic tenet is that abstractions that are designed to save the programmer time inevitably leak, and if they leak at a lower level of abstraction than the programmer is familiar with they prove almost impossible to debug. Paradoxically, the more time saving abstractions you are using the more you actually have to know.

   JavaScript is possibly the leakiest abstraction of them all, thanks to the many different browser environments it runs in. If you rely on a library to abstract away the browser bugs from you you are certain to run in to a bug that you can’t fix sooner or later. Don’t use libraries as crutches; if you’re not prepared to figure out what the library is doing for you you’ll end up in a world of pain further down the line.

4. Community and documentation matter. As with all open-source software, it’s a good idea to get a feel for the amount of community activity around a project before you commit to building on it. The big four all have active communities, which means less bugs, more support and a faster rate of improvement. Likewise, good documentation is invaluable.

5. Libraries should play well with others. Reusable code that excludes other code from being reused has severely limited long-term value. In JavaScript, that means that libraries that mess with Object.prototype or pollute global namespaces should be treated with caution. The Prototype library was a major culprit here, but thankfully has cleaned up its act (at least with regards to altering Object.prototype) in recent releases. It’s all very well saying that you’ll always be using code built with your core language modifications in mind, but you may well change your tune when you try to incorporate Yahoo! or Google Maps and everything breaks.

6. Go with the grain. If you take the time to learn it properly, JavaScript is a powerful and surprisingly elegant language. Good JavaScript code takes advantage of its dynamic, functional nature. Libraries that promise to take the pain out of JavaScript by writing the code for you probably aren’t as smart as they seem. Abstractions leak.

Dan Webb has a good comparison of the big four on SitePoint, although he did overlook YUI’s Animation library which I consider a highlight.

For more accurate coverage of the @media panel itself, take a look at my co-worker Paul Hammond’s detailed notes.