Skip to content

Instantly share code, notes, and snippets.



Created Apr 22, 2011
What would you like to do?
Forrst comment in response to @sneeu's question: Curious to know if anyone’s used Backbone.js, or Spine, or something similar, and had any thoughts on advantages & disadvantages of each.

I can only comment on Backbone.js, which as part of a 10-person team I'm currently using for a medium-sized single-page ('enterprisey') web application on the front-end. I would also say that the app is pretty much a read-only experience in that 99% of server requests are simple GET requests. There is a fair amount of data filtering and a bit of complexity in the view (dragging, scrolling, etc) which made us realise that using jQuery and a bunch of plugins alone would result in a big sloppy mess.

We were looking for something that could handle JavaScript routing and history management, as well providing a structure for separating data from the DOM and jQuery. In the future, we are also hoping to create versions for modern mobile browsers without having to re-write the entire application, for example by swapping out jQuery for Zepto.js on iOS devices. On top of all this we wanted something that would stand up to unit and functional testing without being a major pain in the backside (or backbone).

We looked at Sammy.js and JavaScript MVC in addition to Backbone, but these libraries' dependency on jQuery put us off. If you are already using jQuery or plan on using it for all your DOM manipulation requirements, then these two are worth a look as well.

Here are some pros and cons that we have come across in the course of the project so far. These may not affect everyone, of course, and there are bound to be others.


Lack of UI dependency

Backbone uses jQuery or Zepto.js in the view layer if they are available, but it is certainly not dependent on them. Others have had success using MooTools for example. Its only other dependency is underscore.js which is maintained by the same developer (Jeremy Ashkenas).


... and it's pleasing collection and array methods, which we knew that we would use pretty heavily for filtering and searching quite large sets of data in the client on the fly. We really didn't want to use jQuery utility methods for this. Some are polyfills for native methods that will become available in future versions of JavaScript/ECMAScript, and others are inspired by similar methods from Ruby or Python. I would add that underscore.js can be mixed in to any native array or object, however. You're not limited to Backbone for this.

Model source agnostic

Initially our data is sourced from our back-end application, but we're planning on making use of localStorage for offline usage, and looking at other solutions for performance on mobile. Backbone supports any mechanism you like for RESTful operations using Backbone.sync(). There is already a localStorage adapter for Backbone.js, for example.

Event support

Backbone passes messages between the models, controllers and views using built-in event types, and also provides a mechanism for you to pass your own custom events around. These are very useful for avoiding tight coupling in your code, but again it's a feature that is not unique to Backbone.


Backbone is opinionated enough about how to structure your app that it will make some structural decisions for you. However, you'll still spend plenty of time working out exactly what objects you need to create and how they are related, particularly if you have a complex UI with a lot of varying states.


In our previous project work, we relied on a combination of QUnit, Canoo WebTest and Selenium for our tests, which were heavily weighted towards the functional end of the testing spectrum. They were slow, brittle and a pain to maintain. Unit tests were lacking because we simply lacked the units to test effectively.

Backbone.js insists on the creation of sensible units, making unit testing that much easier. We currently have a suite of 100+ Jasmine BDD unit specs that run in under 0.3 seconds. These specs test all aspects of the Backbone app, including server requests and view rendering. The speed they run at is down to the use of Sinon.JS fake servers and fake timers. I've written a series of blog posts on how to test Backbone.js apps with Jasmine and Sinon if you're interested.

We still use functional tests, but our unit test suite catches most bugs.


Single controller

Backbone.js only allows a single controller to specify URL routes per page. I personally found this slightly limiting having used Sammy.js, which allows you to create as many Sammy 'applications' as you like, each with their own set of route handlers.

This gives you the ability to have each part of a page be in charge of its own responses to a set of routes, another feature that allows code decoupling and improves testability. You can get round it by having your interested objects bind to Backbone's built-in route events, but the route events are only fired for routes that are specified in the single controller. In our application, the controller is really just a route configuration tool and not much else.

History management

This is currently the weakest part of Backbone in my opinion. History management and route dispatching has a major bug in Internet Explorer 6/7, and there is currently no support for the HTML5 history API (pushState, etc.) Dion Almaer has apparently successfully integrated Backbone.js with Benjamin Lupton's more complete history.js library on the FunctionSource site which I am planning to look into.

Early adoption

There are the usual problems with being a relatively early adopter, as derek has already mentioned, in that for every Backbone.js tutorial out there, there is a different approach for structuring your app. For what it's worth, we found a few things early on: Too many Backbone 'classes' is better than too few; use events or pubsub wherever you can; keep as much code out of the controller as possible; and rigorously remove tight coupling.

Nesting / composition

This is perhaps not a con per se, but coming up with an effective object model for your Backbone app can be a challenge. I advise you to read the Nested Models & Collections section in the Backbone docs. You will be doing a lot of this for anything but the most simple apps.

If you've had any experience of UI systems that make heavy use of composition and/or delegation (I'm thinking along the lines of ActionScript 3 and iOS apps here) then you'll feel pretty comfortable coming up with an object schema for your Backbone app.

Above all I have had fun developing with Backbone, chiefly because it has been the most enjoyable test-driven JavaScript I have written.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment