Hey, check out my Backbone
This is the first post in what will become a series of posts covering Backbone.js. I’ve been developing Backbone apps pretty heavily lately and have learned a lot. This series will serve to document what I’ve learned for personal purposes, and hopefully will be helpful for developers looking to learn more about it.
What’s a Backbone.js?
You’ll often hear Backbone referred to as a client side MVC framework, like Rails or ASP.NET MVC. I disagree with this comparison. While its useful to provide context for what Backbone can do, it leads down a very confusing path where many incorrect assumptions get made.
These bad assumptions often get made because of an unfortunate naming choice early on in the framework’s development. In previous versions, the Backbone Router was actually called “Controller”. Thankfully, right around the 0.5.3 release, Jeremy Ashkenas and team decided to rename “Controller” to reflect its actual purpose: a Router.
Confusing naming conventions aside, I like to call Backbone an MV* framework, where the * is basically a wild card (you could go with MVC, MVP or MVVM). Backbone has Models and Views. It does not, however, come with a baked in Controller (in its most current form). Because of the unfortunate naming mishap in earlier versions, many demos you’ll run into out on the web will treat the Router as if it were a Controller. While this works from a technical standpoint, and is often the simplest implementation, I’ve found that it tends to lead toward a more limited understanding of the framework. I’ll get into more detail on that later on in this series.
I’m not going to go super in depth about each individual part of Backbone just yet, but here’s the 10k foot overview:
Like in most MV* implementations, in Backbone, models represent your data. They also have a lot of nice utility methods to handle data transport. You can tell a model where it lives on the server by passing it a RESTful URL root. And should you ever call ‘save()’ on that model, it will know how to persist itself. And, of course, you’ll want to place much of your domain-specific business logic in these model objects.
Backbone collections are basically lists of models. The really nice thing about the way they’re implemented. Thanks to Underscore, it’s really easy to query, slice and dice your data on the client.
Underscore.js is a dependency of Backbone and is super useful in its own right. Underscore provides lots of nice utility functions that Backbone hooks into. Underscore is to plain ol’ JS as jQuery is to the DOM.
Views are the representation of your UI reflected as code. You get a lot of flexibility in how you choose to implement them, though. They can already exist on the page (rendered by the server), or you can populate templates (HTML fragments) with data from your models and have the view render them on the page.
Views can listen for DOM events via jQuery or Zepto (whichever you happen to be using). This often makes Views feel a bit like Controllers in that they are often the entry point for user interaction in your app.
As I mentioned earlier, a lot of people make the mistake of thinking of the Backbone Router as a Controller, simply because it handles incoming URLs in a similar fashion that server-side MVC developers are often familiar with. In an upcoming post, I’ll be diving into the pattern I use to avoid falling into this trap.
Internally, Backbone uses an object based event binding system to enable a really elegant publish/subscribe implementation. You can use this feature to listen for events fired by models and collections. You can also extend this functionality to create your own event aggregator for your app, allowing different constructs or modules to talk to each other without unnecessary dependencies.
Individually, these pieces aren’t super special, but as a package, they become really powerful. It’s also important to note that Backbone plays really nicely with other JS libraries, so it’s very easy to mix and match things to create your own stack.
In my next post, I’ll be digging into the MVP (Model View Presenter) pattern that I use to build apps, and why adding a bit of your own opinions into Backbone can be really important and highly beneficial.