Our new product Ginger relies heavily on Backbone.js for most of the client-side functionality (you can read about our full web-stack here). Our JavaScript guru Marco built the initial prototype and then was pulled away by client work. I reluctantly filled in, but my background is primarily in Django. My JavaScript experience was minimal (primarily stitching together jQuery plugins to get the desired effect).
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.
Terminology
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.
Events
Events are what separate client-side development from server-side development. Events allow you to immediately update portions of the page based on some event triggered by the user1 (click, hover, etc.) or a change in the underlying data2 (model updates, addition of a model to a collection, etc.). Sure you could do this all along with jQuery or even plain-old JavaScript, but Backbone makes working with events much, much easier.
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 :)
Router
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 model and/or 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 AppView).
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.
Views
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.
Backbone is template-engine agnostic, so you’ll need to bring your own. Since underscore.js is already a requirement, using its template engine is a quick way to get started7.
Models
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.
Collections
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.
Next Steps
Hopefully this introduction is enough to get a few Django developers over the initial hump of picking up Backbone. If you wrote JavaScript without jQuery in the past and remember the massive improvement jQuery made, making the leap to Backbone (or another client-side MVC framework) feels similar. You’ll find it indispensable and wonder how you lived without it very quickly.
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!
