For a few days, I’ve been learning backbone.js. Backbone.js will be an important part of my web applications, even the simple ones. That is because backbone.js can quietly clarify my work in the browser without getting in my way.

Henrik Joreteg wrote that there are five steps to embracing backbone:

• storing data in the DOM
• build some models in Javascript
• build spaghetti code from the model and UI bindings
• create your own organization for these bindings
• discover that backbone.js did a better job than you did

My problem is that I’ve gone through the first three steps of this, without figuring out my own organization. So, learning backbone for me was about realizing that some of the same organizational principles that drive the code on the server also apply to the Javascript code in the browser.

For a Rails programmer, I’d suggest getting started with James Yu’s article on backbone.js with Rails. He’s created a nice demonstration Rails application to go with the tutorial.

The main thing this article does is clarify how to keep the Backbone files as neat and useful as RESTful resources. He organizes his Javascript in the same way as a Rails app organizes it’s files. He uses jammit gem for asset packaging. Incidentally, jammit is written by the same folks that brought us backbone, DocumentCloud.

James also clarifies how a controller can be used effectively with backbone. He uses it to define routes and create thin methods that

• transport the data to and from the server
• process the data for the views
• instantiate the views

So, very useful, these ideas. Trying to summarize this and about 50 other ideas, I’ve realized that backbone helps me stay:

• thin
• synced
• conventional
• responsive

Stay Thin

It turns out that thin controllers in the browser is as important as thin controllers on the server. Controllers are meant to keep the data traffic organized and well directed, that’s all.

The models also can be quite thin in the browser. I can do a little validation work with them, and I will often set a url in them so that my controllers can fetch data elegantly. The important thing for me is that they are there, so that it’s easy to build a view with a template and the attributes I have in my models.

Stay Synced

With Javascript, binding events can make a page quite dynamic. It’s important when changing part of a page that the rest of the page stays in sync. Henrik Joreteg wrote a great article for explaining how this works. His views bind some model changes directly to view changes.

This is an area where the code can get messy. The way I’m thinking about it today is that the main activity in a browser is to click on links and fill in forms. For these kinds of activities, I use the Backbone controller and its routes. Outside of the main activity is the context of the activity. Sidebars, statistics blurbs, titles, and headers can all reflect the main work that’s changing in the browser. These types of components create a contextual backdrop for the application. These should probably bind to models and collections directly.

Stay Conventional

Additionally, there are a few conventions in backbone that make all this work easier. I read a particularly useful comment in StackOverflow that helped me see how the model and collection ‘url’ property can be used to fetch data from the server more elegantly. The backbone documentation is quite good and points out the subtle conventions while setting up a view. There are 4 things that backbone does when it sets up a view:

• it stores the configuration properly
• it creates an element reference in the el property, if one hasn’t been setup
• it sets up the bindings
• it calls initialize

Stay Responsive

Since I’m coming to the party unorganized, I’ve had to come up with how I see and think about the backbone views. I think of them as primary views, resource views and contextual views. Primary views are often anchored to a part of the DOM when a page is loaded. Often I’ll have an empty div just waiting for Backbone to fill it with something useful. I think of resource views as the resources the main flow of the page needs, the kind of thing I have as a route in a controller. These are forms and things that are still the primary utility of the page, but they’re not necessarily setup when I open the page. For these views, I don’t set an el property, but only tell the view how to build one when it’s time. Finally, the contextual views are the peanut gallery. These are components built to comment on the main activity: search forms and side bars and headers and such. These may or may not be anchored to a particular part of the DOM. They’re the indirect side effects of the users activities.

Setting up the element property (el) is generated with the Backbone.View make function, which is a pretty handy way to take a tag name, attributes, and content and create a view with it. Backbone is looking for the tagName property to be set. It will optionally use the id and className properties if they were setup in the view. So, when I’m setting up contextual views or resource views, I just have to think about how I want to have the element prepared, and I can often do it in configuration.

Of course, the render on a view can do anything to the el property. I’ve been quite impressed with the ICanHaz.js templating system. It uses moustache templating that are neatly loaded into the ich namespace at runtime. That way I can set an element with something like:

$(this.el).html(ich.summaryView(this.model.toJSON()));

That takes the current contents of my model, sticks it into the template, then sticks that into my view’s el property. Not bad for a one-liner.

All told, backbone.js offers a quiet clarity to my code. Every piece stays organized without getting too heavy or obtrusive. To re-retweet this morning’s tweet, a quote from Leonardo da Vinci:

Simplicity is the ultimate sophistication.