Topics
Social
Subscribe

Lessons Learned From Backbone.js

At a recent Software Developer conference, Codemash 2013, I had an opportunity to hear a talk on Backbone.js. Backbone.js gives structure to web applications by providing models with key-value binding and custom events, collections with a rich API of enumerable functions, views with declarative event handling, and connects it all to your existing API over a RESTful JSON interface. Basically, it is an MVC framework for javascript. It allows you to abstract your data into models and your Document Object Model manipulation into views and bind the two together using events.

Chris Nelson, the presenter, spent the first part of his talk explaining the benefits of the Rails Asset Pipeline. It bundles up and minifies the css and javascript and handles dependencies. For .Net folks, the bundling and minification framework in MVC 4 has a lot of the same features. These tools can help organize and optimize any project, but are especially useful in projects with complex javascript.

After gushing about Rails, he finally got around to talking about Backbone. Backbone is basically an MVC framework for javascript. Backbone doesn't come with a template framework, but it is generally used with one, such as ECO(Embedded Coffee Script), HamlCoffee, EJS, Jade, or Handlebars. It's a very handy way to separate the app logic from the generated html.

He also brought up some issues with including a sub-view within a template. If you try to just include a sub-view within a template, the event binding for the sub-view won't get wired up right and it just won't work. You can work around this issue by passing the parent view to the child view and binding to the parent's rendered event. Then you create the event bindings for the sub-view events after the parent has rendered and everything will just work.

Another potential issue that was brought up is that in some cases, views that are created and destroyed frequently (like a scrolling calendar app) will cause memory leaks. If the views are not bound to the model properly, they'll hang around after they've been destroyed and still handle events and take up memory. This is caused by binding the model to the view with Model.On(). The model holds on to the view, so it won't go out of scope to be garbage-collected. The easiest way to fix this issue is to flip the event binding and listen for the event from the view with listenTo(). There’s a neat Google Chrome feature called Heap Snapshot that can help debug run away memory leaks. It lets you take a snapshot of the memory at a point in time and compare it to another snapshot. You can see what objects are hanging around in memory and find potential problems.

Here's another reason why Chrome is awesome: it has a built in javascript “prettifier” (it's the button labeled “{ }”).

Continue Exploring

Approach

Culture

Careers

Our Work Services Commerce Cloud Approach Culture Blog Careers Contact

3344 Grand Ridge Drive NE
Grand Rapids, MI 49525
616 365 1000