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.
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
- DOM manipulation / traversing
- Event management
- 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:
- When you want to use Array extras (
Array.map, etc.) in older browsers.
bindAllare handy in browsers where
Function.bindisn’t an option
- When you need a lightweight template function. Underscore’s
templateis a slightly modified version of John Resig’s micro-template function
- 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?
- 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.
- If you’re trying to manage a lot of events, Backbone’s View is very handy.
- If you need to control and respond to browser history with hash URLs or using pushState, Backbone’s Router is worth looking at.
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.