JsonData

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?

Backbone.js is a JavaScript framework. Lots of people like to use it to build larger scale applications that run in a web browser, completely decoupled from their server framework of choice. It’s an incredibly powerful tool to have at your disposal. There’s so much information and buzz out there about this framework, though, that I think it may be best to start off describing what Backbone isn’t.

Huh?

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:

Models

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.

Collections

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

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.

Routers

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.

Events

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.

History

Backbone’s implementation of browser history is where a lot of the magic happens. It watches the URL hash, or listens to PushState (if your app uses it, and the browser supports it), and will send the URL changes to your router to handle. This is really nice in that you can add bookmarkability into your single page JavaScript applications for free.

Wrapping up

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.