After a month or two of being submersed in Backbone, I’ve seen the light and am now relatively competent. When I got started I was completely lost. Here are some things that probably would have helped me back then. Whenever possible, I’ve linked to the source of the Backbone Todo example for code samples.
In many ways, Backbone and Django are similar. They’re both MVC-like, but some of the terminology they use is different. Here’s a quick map:
- Backbone → Django
- Events → Signals
- Router → urlpatterns
- View → View
- Model → Model
- Collection → Queryset/ModelManager
These certainly aren’t 1:1 matches, but it should help you get comfortable.
Like signals in Django, events can be difficult to troubleshoot and result in non-linear code paths. When you first start working with them, you’re likely to pull your hair out troubleshooting them. Don’t worry, it’ll get better with practice :)
Similar to Django’s
urls.py Backbone’s router (often living in
Router.js) maps URLs to views. Typically our routes do heavier lifting than Django
urlpatterns. Backbone views accept a
collection as arguments, so our routes usually build or grab these data structures and pass them to the parent view (commonly referred to as an
As you can see from the Todo example, a router is completely optional. Only use one if you need to map different views to different URLs.
In both Django and Backbone, views take some input and render HTML. They typically have multiple methods like a Django class-based view. That’s where the similarities stop, however.
The biggest paradigm shift for me in Backbone is that a single page is made up of many views often nested inside each other. In Ginger, we have a page that renders the list of comments in a discussion. The router finds the discussion model we need and then creates a view for it. That view iterates over the comments on that discussion (stored as a Backbone
collection) creating a view (nested inside the discussion view) for each comment in the collection.
Organizing and nesting your views in this manner has a lot of benefits when you are doing event-based programming. The outer view3 can handle adding/removing items4 from itself and instantiate5 individual inner-views6 that can easily modify each model based on events that happen within their DOM container2.
A model is an in-memory object with arbitrary attributes (no need to define the fields like Django). Events can be bound to changes in those attributes.
Using the same example from Ginger, a single comment view binds to the
change event on the comment model instance. When any attribute changes in the comment, the
change event is fired and the view re-renders the comment so the changes are reflected in the DOM.
Models are designed to be easily fetched and saved8 to a server. Backbone handles the AJAX for you. Similar to Django, we prefer to move as much logic out of the view and into (easily testable) model methods9.
A collection is a group of instances of a specific model. Like models, they can easily be fetched10 from the server. Like querysets in Django, a collection instance can be filtered, sorted, and sliced. The collection object itself can have methods attached to it11 like a
ModelManager in Django.
For me, the best way to understand a new language or framework is to use it. Grab the Todo example and play around with it or just start building something of your own. Like Django, you’ll find lots of work has gone into Backbone’s documentation. It’s a quick read and an easy to reference to fill in the gaps as you go. Good luck!