Why we use Backbone.js

At VI Company almost all of our projects use Backbone.js and while we regularly take a look at other, more popular frameworks, like AngularJS and React, Backbone.js is still our go to library. In this article I will explain why.

Not a framework

It’s a library, not a framework. This means it’s small, relatively easy to learn and doesn’t restrict or force you in a certain way of working. Just read the Getting Started about the underlying philosophy:

“In an ecosystem where overarching, decides-everything-for-you frameworks are commonplace, and many libraries require your site to be reorganized to suit their look, feel, and default behavior — Backbone should continue to be a tool that gives you the freedom to design the full experience of your web application.”

This also means there's “more than one way to do it” when working with Backbone.js. This can be a bit daunting for beginners, but for the more seasoned developers there isn’t much magic involved by using Backbone.js.


Less is more especially when you are talking about page weight and developing “Mobile first”. Backbone weighs a mere 7.3kb when minified and gzipped. It used to have a hard dependency on jQuery, but since version 1.2.0 it’s quite easy to get rid of that. The other dependency is Underscore.js (5.7kb, Minified and Gzipped), but we use that most of the time for it’s templating functionality and it also brings a lot other useful utilities.


Backbone.js has been created with extensibility in mind. Therefore a lot of small libraries are available that fulfill a certain need. Need more control over view rendering? Use LayoutManager. Need better Model-View binding, use Backbone.Stickit or Epoxy.js. Do you need more structure and some magic for your Single Page App? Use Marionette. And when you fancy some Virtual DOM, you could also use React as your view engine. Or you could just write your own base View/Model/Collection if you want to.

Documentation and API

The first 0.1.0 version was released almost 5 years ago and the development has been going strong ever since. The API hasn’t changed much since then and it can be learnt in a day. It’s well documented, including the annotated source, which is a great resource for learning JavaScript. It’s heavily tested and off course you can try the obligatory TodoMVC example. There’s also a list of tutorials available and its creator, Jeremy Ashkenas, also gave us Underscore.js and CoffeeScript; two highly regarded JavaScript projects.

MV* Structure

Backbone gives structure to JavaScript projects and incorporates the basics of Object Oriented Programming. A skill that is still missing with a lot of JavaScript developers today (and no, knowing jQuery doesn’t make you a JavaScript developer).

One of the first things Backbone teaches you is to move away from the DOM and use a RESTful API to retrieve JSON and store that data in your Models. Connect your Views to those models and let them respond to changes in the associated model to render new HTML and update specific parts on the page.

Addy Osmani has written a comprehensive article on MV* for JavaScript and Backbone.js developers.

Progressive enhancement

We build a lot of public websites which need to be SEO friendly and accessible to users with older browsers. We use the Progressive enhancement principle when creating websites and Backbone.js nicely plays along in enhancing the page. And when using a template engine like Mustache or Handlebars, we can even share the templates between the Front- and Back-end, so we only have to write that code once.

Isomorphic JavaScript

While React is mostly seen as the framework for Isomorphic JavaScript apps, there are also a few frameworks like Rendr from Airbnb or LazoJS from Walmart, that use Backbone.js as their basis. So when you already have some Backbone knowledge, you can pretty easily make the transition to writing server-side JavaScript without the need for learning a new “magic do-it-all” isomorphic framework.


I don’t like to reinvent the wheel and I dislike the magic, steep learning curve and the vendor lock-in that larger frameworks tend to bring to the table. And surely, when creating a private Single Page App we will reconsider Angular, React or something else, but when it involves a public and informational website, we will likely use Backbone.js again.

More information