I have a tendency to use Backbone.js like it is part of Rails. I don’t think I’m the only one. But why is Backbone so popular? Or maybe a better question to ask is when do you know that it is time to use Backbone?
There are two parts to this question. The first is: when should you build a single-page application (SPA)? And the second is: which javascript framework should you use if you are going to use one?
Let’s call an SPA any app where the content of the view changes dramatically without fetching a new page from the server. This might mean adding or removing subviews, or swapping out the whole view. A pure SPA will only retrieve html once and all subsequest requests to the server will be asynchronous data requests. When asking yourself if you should move toward an SPA consider the following:
Do you want users? Seriously though, do you want users or visitors? Should people interact with your site or should they just look around? If you want users that interact with your site (and continue to interact with your site) then you need to constantly feed them new content. Every round-trip to the server for a new page means another user lost to facebook (half-SPA) or gmail (pure SPA). User boredom is real! As I mentioned in a previous post, Google and Bing have found that even server delays of less than half a second affect user engagement. If you still need convincing here’s another example. With mobile and native apps taking over the world, user expectations are on the rise so that, when it comes to web apps, only the fast will survive. And fast means Javascript and SPAs. Slow means servers.
What other endpoints does your application have? Nowadays its very possible that you’re building an iOS front-end as well as a Google Glass front-end as well as an inflatable jacket front-end. All of these will be exposed through an API. Why would you give the browser special treatment? Do you get lonely when your developers go home so you want to make extra work for them? That second set of routes and second set of controllers just lying around is code that smells worse than a bag of dirty diapers on a hot day.
Would you want to live in a place that had to reload every time you touched something? This is not a philosophical question. Consider how much of our lives are spent with screens.
Assuming you do want to move toward an SPA, you are going to need some javascript. You could build what you need from scratch or you could use one of many javascript frameworks including Backbone.
Why would anyone want to build a framework from scratch? You’re going to need views, events, data modeling and routing, all of which have been built many times over by someone else. The drawback to frameworks, in general, is that by depending on them you become less agile. Maybe the framework you choose solves your current set of problems perfectly but then your next set of problems is more complicated and outside the bounds of what that framework can do. A friend from Etsy told me this was their problem with Backbone when they needed validations that work with international translations. When you reach the edge of your chosen framework your choices are to hack in a workaround, fork the framework, or submit a patch and hope for the best. None of these are particularly savvory options. Another concern is that the maintainers of the framework will abandon it. This is related to the issue of competition, which is the most unpredictable of issues surrounding frameworks. It is inevitable that eventually something better is going to come along and you’re going to wish you weren’t in a committed relationship. Take a look at this to get an idea of how revolution can be right around the corner. And keep in mind that your whole codebase could suffer if you are using out-of-date technologies because good developers will be less inclined to work for you.
Building successful applications is about making the right sacrifices. Maintainability is the loftiest of goals but you cannot prepare for everything. Most importantly, you need to build something that thrives in the present. In this particular present (November 2014), that means avoiding the monumental task of building your own custom framework and choosing between Angular.js, Ember.js, and, of course, Backbone.js. While they all accomplish basically the same thing for users(a fluid UI), there are some not-so-subtle differences for developers.
The one thing to consider as far as user experience is the size of the frameworks. Presumably, if you’re building an SPA you care about speed and, consequently, the size of your assets. Backbone, at 6.5kb gzipped and minified, is the lightest weight of these three frameworks, while Ember, at 90kb gzipped and minified, is the heaviest. This is slightly misleading because, once you add jQuery and Underscore to make Backbone operational, it weighs in about equal to Angular with its 39.5kb. But this fact about size tells another story, too. Backbone is by far the least opinionated of the group. It is smaller because it does less. And that is, ironically, the most compelling reason to use it. If choosing a framework makes you less agile, you should choose the one that is the least framework-y. The point of using a framework is to avoid the endless hours of slaving over nitty-gritty plumbing, not to build the actual application for you. You want to retain as many choices as you possibly can. Everything Angular and Ember provide can be added to Backbone quickly and easily, either by building it yourself or by selecting a plugin (selecting a plugin is still a choice and still agile).
For example, both Angular and Ember provide two-way data binding to make sure that your views and your models always keep each other up-to-date. That’s great but it is not really a slight against Backbone since you could add that logic yourself or use one of many model binding plugins like stickit. This example shows how Backbone really isn’t much more than a starter pack for building a more complete framework. There are many frameworks built on top of Backbone like Aura, Backbone UI, Chaplin, Geppetto, Marionette, LayoutManager, Thorax, and Vertebrae.
Another important consideration, as far as developer experience, is community. You can waste a lot of time figuring things out yourself. It is much better to have an active community that you can turn to for help breaking through walls. In this respect, Angular wins handily. Compared to Backbone, Angular has more than twice as many Github contributors, StackOverflow questions, third-party modules, and youtube results. On the other hand, without understating the significance of community, Backbone is so much more straight-forward that you will simply have less questions.
You won’t find anything in Backbone that compares to the confusion of Angular. Backbone just doesn’t try to go there. What’s more, Backbone has admirably clear, concise documentation. If you want to know what I mean, take a few minutes to read the complete annotated Backbone source code. Then when you’re done with that, try reading Ember’s source code.
One more potential criticism of Backbone is that the views are more closely tied to the DOM making unit-testing harder. One of the great advantages of modular js frameworks is how much easier they are to unit test. Being tied to the DOM makes tests not worth the headache of setting them up. I find, however, that that’s not so bad. You can still unit-test everything that doesn’t interact with the DOM and for the rest you have your integration tests.
In my humble opinion Backbone makes all the right sacrifices. If you want to build an SPA and you don’t want to rebuild the whole thing in a couple of years and you don’t want to waste your time building things from scratch, use Backbone and then try not to read about new technologies.