Posted on by & filed under javascript, programming.

At Safari we use a variety of JavaScript libraries. As we have expanded and started new projects the question: “how do we choose when to use what library?” has come up a few times. I’ll go through my general approach to choosing a JavaScript library and then talk over specifics around the three main libraries we use at Safari: jQuery, Underscore, and Backbone.

Deciding Which Library You Need

Generally you start with a problem. I first want to make an observation about jQuery plugins becuase I think it’s where a lot of people start when looking for a solution (I know it was for me). Many who already use jQuery will just get out their Google hammer and search for “jQuery + [insert problem here]”. There is a jQuery plugin for pretty much anything you’d want, but I think coupling all of your libs could lead to problems later. If all the plugin does is attach a few methods to jQuery.fn, then my advice would be to look for a jQuery-free version. The added benefit of a jQuery-free library is that if you ever decide to switch from jQuery to something else, you’ll have less code to convert or find a replacement for.

OK, so sometimes a jQuery plugin will be your solution, but I want to start earlier in the decision process than that: start by thinking about your problem and ask yourself “is JavaScript the right tool to solve this problem?”. If your answer is “yes”, ask yourself the question again. I’m not trying to be a jerk, it’s just that CSS3 can do a lot of things that used to solely be in the realm of JavaScript. Now it’s better to write a CSS class to do that and then use some lightweight JavaScript to add or remove that class when appropriate. Just because modern browsers can handle most of the JavaScript we can throw at them doesn’t mean our users (and their networks) should have to.

If JavaScript definitely is the answer, then there are a few criteria to use when deciding on a library.

Does it do what you want?

If it doesn’t do what you want, then obviously, you want to keep looking. The other thing to look at here as well is compatibility: will it work in the environments (mobile browsers, desktop browsers, node) you need it to?

Do you like the API?

Read through the documentation (no docs? we’ll hit that one next) and try and get a feel for how the library is used. Do you like the choices that were made during the API design? If you were to using this library on a daily basis, would you enjoy it?

Is there documentation?

While most of us are capable of digging around in the source to figure out what’s going on, it is great when we don’t have to. Just a list of API methods with their corresponding docstrings is often passable, but I prefer documentation that is more user-friendly.

Are there tests?

Having tests is a good sign in a project. It helps to keep the codebase stable and allow others to commit to the project more easily.

Has there been recent activity on the project?

Though this is not always an indication of quality, I’m usually more comfortable using a project that is actively maintained. It makes me feel like bugs in the project will get worked out in a timely fashion.

Deciding When to Use a Library

The three main libraries we use heavily at Safari are jQuery, Underscore.js, and Backbone.js. I think all of them meet the criteria outlined above, but knowing when to use each of them is not always straightforward.


For me, jQuery is the tool I reach for whenever I have to do anything that involves

  1. DOM manipulation / traversing
  2. Event management
  3. Ajax anything

Lately I’ve also found jQuery.Deferred to be useful in some cases (and really fun to use). jQuery’s great because of it’s ease of use (I remember my initial reaction to jQuery being something like: “All I need to do to get started is read some documentation and throw around some CSS selectors?!”), and the cross-browser differences it smooths over.

More recently, I’ve been tinkering with the idea of only loading jQuery for older browsers that need compatibility and using something smaller like Zepto or Ender for my DOM needs. Though if this commit or this tweet are any indication, maybe jQuery’s 2.0 will be that smaller alternative.


Underscore.js provides a bunch of utility methods for dealing with Arrays, Objects, and Functions in a functional programming style. The cases where to use Underscore are:

  1. When you want to use Array extras (Array.foreach,, etc.) in older browsers.
  2. Function.bind – Underscore’s bind and bindAll are handy in browsers where Function.bind isn’t an option
  3. When you need a lightweight template function. Underscore’s template is a slightly modified version of John Resig’s micro-template function
  4. Many other instances—really it’s just very useful, go take a quick skim through the documentation, there’s a lot there.

I like that Underscore is already pretty small (4kb minified and gzipped according to the site), so I don’t often fret too much about size when I think it might be nice for something I want to do. If you’re size- or performance-obsessed though, you might want to check out John-David Dalton’s lo-dash. You can do custom builds, and the focus is more about cross-browser consistency and performance where Underscore’s is generally more focused on spec compliance.


Backbone relies on both jQuery and Underscore (or one of the alternatives I mentioned for each of those ie., jQuery can be swapped out for Zepto or Ender and Underscore can be swapped out for Lo-dash), so while it’s fairly small itself (6.3kb), there is a bit of overhead associated with its dependencies.

When do you use Backbone?

  1. Single page applications. These have become popular as of late, if you’re not sure what that phrase means, check out the examples on Backbone’s site – most of them are “single page applications” where Backbone is controlling the routing.
  2. When your code feels like a tangled mess. The first time I used Backbone was because I was looking for a way to organize a bunch of spaghetti jQuery code. Backbone’s abstractions of View, Model, Collection, and Router often fit with things you’re already doing once you get to a certain complexity in a JavaScript application.
  3. If you’re trying to manage a lot of events, Backbone’s View is very handy.
  4. If you need to control and respond to browser history with hash URLs or using pushState, Backbone’s Router is worth looking at.

Backbone is a MV* framework, one of many in JavaScript, but what I like about it is its flexibility and the fact that’s it’s fairly bare-bones (seing a common pattern here?). It’s just enough to do what you want and then get out of your way. Some think this leads to too much boilerplate code, but for me, it lets me do things the way I want.

We have other libraries we use as well, but some combination of these three form the base for most of our projects. They might not work for you and your team, but I highly recommend settling on some standard libraries so that don’t have to learn a new library on each new project.


One Response to “Choose Your Libraries Wisely”