Feed Sign in with OpenID OpenID

Simon Willison’s Weblog

Notes on JavaScript Libraries

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

This is Notes on JavaScript Libraries by Simon Willison, posted on 26th June 2006.

Tagged , , , , , , ,

View blog reactions

Next: LUG Radio Live and Ask Later

Previous: Fjax: Just say no

19 comments

  1. I'm really surprised at the lack of discussion concerning the jQuery Javascript Library. It's popularity is exploding, especially considering that Drupal has chosen it as its Javascript library for Drupal 4.8. Even the comments of the "Big Four" article are flooded with people wondering about jQuery. Finally, as to point #4, jQuery has some excellent documentation and a booming community, with over 250 people making over a thousand posts per month.

    John Resig - 26th June 2006 15:29 - #

  2. Nice summary.

    Dado - 26th June 2006 16:09 - #

  3. John: I've been a little cautious about recommending JQuery because while the external API is absolutely beautiful the actual library code is pretty hard to read - which goes against my point above about the law of leaky abstractions and always using code that you are willing to read, understand and debug.

    To be honest, my initial impression of JQuery was that it was an interesting hack that I wouldn't want to rely on for production. The size and quality of the community and the number of eyes on the code is causing me to reconsider that impression though - I plan to look at it in a lot more detail, and I certainly wouldn't advise people against using it.

    I may have to expand the big four to the big five.

    Simon Willison - 26th June 2006 19:26 - #

  4. Glad to see you reconsidering, Simon. A couple points to consider, as to the readability of the code.

    The default version of the code comes compressed using Dean Edwards' Packer, (Dean is also a big fan of jQuery and frequents the mailing list) so that in and of itself may scare some people away. However we also provide readable source to anyone interested, both in the form of a SVN repository and un-compressed packages.

    As to the direct readability of the code, I'll admit, it has been lacking. This has been a major concern of mine for the upcoming 1.0 release of the library. Inline documentation, highly-commented code, and self-explanatory variable names are all items that I've been working to achieve with this new release (which is due out in about three days).

    I'll be sure to let you know when it's released, so that you can pass your discerning eye over it.

    John Resig - 26th June 2006 21:10 - #

  5. a comment on jquery since the esteemed mr resig has chimed in - i am playing with jquery on an internal throwaway app, its nice in many ways, it offers some nice idioms and a compact syntax that seems to awaken the same part of my brain as perl...but the documentation is all over the place. since jquery is so different, documentation is key.

    the yahoo libs will have some success, i have been using them for some time. their design is clear and verbose (maybe a little much so, but this appeals to a lot of people), and they do work as advertized. the yahoo docs are also good. including non-yahoo people into the process in a meaningful way will be a key challenge, as with any company-sponsored open source projects.

    there will be a shakeout in this market. there is lots of activity in this market because many people saw an obvious need that could be quickly filled at exactly the same time that the market was deeply enamoured with dynamic sites. within two years this attention will have waned, the browser abstractions commoditized, and no doubt some of the coders will simply lose interest in what may seem a fringe project. i predict only three will have a viable future (three just seems to be the magic number in many code markets).

    the darkhorse is microsoft. they have a lot they can do here to make or break these markets. obviously they control what level of js support the middle of the market is going to get. they can also integrate tightly into the OS. so i give them an automatic pass to the second round since they still make markets in the browser space. oddly, the original source of much of the attention surrounding dynamic sites, google, seems to be absent from all of this. they might be on to something, i don't see many dollar signs at the end of this toolkit war.

    grumpY! - 27th June 2006 06:20 - #

  6. @John - you mean that the compressed code is scaring people not my presence on the mailing list right? ;-)

    Dean Edwards - 27th June 2006 11:31 - #

  7. Don't forget about QooxDoo library (http://www.qooxdoo.org), it is a large set of different widgets that can be used for creating really impressive user interfaces.

    DEkart - 28th June 2006 09:43 - #

  8. Has anyone tried the Atlas framework from Microsoft?

    Stephen Marx - 28th June 2006 10:01 - #

  9. Stephen: From what I've seen of Atlas it's main focus is making Ajax development possible within the Visual Studio IDE. It doesn't help that they distribute it as a .msi file, making it a pain to try out on a non-Windows machine. Also, I've read that their approach to cross-browser compatibility is to emulate IE's non-standard APIs in the other browsers, which doesn't appeal to me at all.

    I'd love to see a good impartial write-up about it from someone who doesn't use ASP.NET.

    Simon Willison - 28th June 2006 10:57 - #

  10. You made this point many times: There are a number of problems in JavaScript (most of them originating with browser incompatibilities). Strictly speaking, general compatability with the ECMAScript standard is quite good. The nightmares are all in the DOM. The DOM is not JavaScript. The DOM is the interface that the browser offers to JavaScript and (potentially) other languages. If browsers supported <script type="application/python"> (and I think that they should) then you would still suffer from the same portability and platform weakness issues. I really liked the comment about abstraction leakage. Some people tend to get very excited about the demo that shows that you can build a complete application with only 10 lines of code. But it often turns out that there are clear benefits to knowing what you are doing. Ignorance can only get you so far.

    Douglas Crockford - 28th June 2006 16:50 - #

  11. I've tried all of them to some extent, and I'd tend towards YUI for a really big client side app (drag/drop etc) because of the documentation, but JQuery for most things.

    I think it was brought up in the panel (all very good by the way), 90% of sites & applications probably only require a few core things - dom traversal/manipulation, proper event binding, a little AJAX and a maybe couple of spiffy show/hide effects for polish. That's the "lighter" area JQuery fits quite nicer (if the docs are improved a bit!)

    If you are writing something complex though, then the chances are you're using a web framework on the server side too, be it Struts, Spring, .Net or Rails. Most of these are starting to bundle a JavaScript library of choice with them - largely to bind AJAX functionality in. So it's going to be decided for quite a lot of folk. In my own J2EE area Dojo seems to be the one getting the traction.

    One of the nice thing about some of these libraries is they're actually making using JavaScript fun again, as the core problems seem to be being solved. Rather than the pulling teeth it was sometimes a couple of years ago..

    John Greenaway - 28th June 2006 19:04 - #

  12. Douglas: I completely agree; that was sloppy writing on my part. I really meant incompatibilities in the browser-based JavaScript environment (a.k.a. the DOM). The language itself tends to work extremely well across browsers, with only occasional slipups (string.replace() not taking a callback in earlier versions of Safari; the trailing comma problem with arrays and object literals in IE).

    Simon Willison - 28th June 2006 19:22 - #

  13. "Ignorance can only get you so far." - My thoughts as well. It's when you become dependent on macros that you have less control over - you begin to get into trouble.

    Dustin Diaz - 29th June 2006 23:51 - #

  14. With regard to Microsoft's Atlas framework, I had a look at this a few weeks ago and quickly dismissed it as the included javascript appears to weigh in at over 300K! (Just create an Atlas ASP.NET page, browse to it, view source, then copy-and-paste the included javascript file's URL - which is something like 'WebResource.axd?[long query string]' into your browser, go to File -> Save As then view the saved file's properties). Plus, the fact that the javascript file is included with a querystring is hardly going to help browser caching.

    Ian Oxley - 19th July 2006 15:17 - #

  15. "Ignorance can only get you so far." - My thoughts as well. It's when you become dependent on macros that you have less control over - you begin to get into trouble.

    DG-10 - 27th July 2006 21:13 - #

  16. >"Note to spammers: Links from this site will..." You realy speak with bots?!

    Note to spammers - 30th July 2006 00:01 - #

  17. Microsoft's Atlas framework generate 300K only when project is set to debug ... http://weblogs.asp.net/scottgu/archive/2006/04/11/ Don_1920_t-run-production-ASP.NET-Applications-wit h-debug_3D001D20_true_1D20_-enabled.aspx

    Petr Snobelt - 8th August 2006 12:54 - #

  18. Zusätzlich zu diesem holen das Wachstum von AJAX und das gegenwärtige Interesse an Netz 2.0 viele neue Leute zu auffangene, die nicht die langen harten Jahre das obskure Wissen erlernend verbringen möchten, das erfordert wird, mit Datenbanksuchroutinewanzen und API Unterschieden zu wringen.

    A2D Web Solutions - 25th September 2006 23:36 - #

  19. I'm surprised Openlaszlo wasn't mentioned. The upcoming DHTML kernel will allow developers to run apps directly in the browser. On the other hand, apps can still be compiled for Flash if necessary. We're doing the latter at work because we need the drawing capabilities.

    In any case, the Openlaszlo folks are receiving some serious funding at the moment, so it seems they'll be contenders sooner or later.

    Denny - 2nd October 2006 23:29 - #

Comments are closed.

Previously hosted at http://simon.incutio.com/archive/2006/06/26/libraries

A django site