Backbone.js LogoiLearn how to optimize your Backbone.js view for better performance

In the first part of this series:  Getting Started with Backbone.js Views – Part I : Introduction, we learned the basics of how to implement a view in Backbone.js. Although the process of extending the Backbone.View class was quite similar to extending the Backbone.Route constructor, our code was not efficient. There are two areas to address: 1) Multiple constructor instantiations, and 2) Separation of presentation and data.

Multiple constructor instantiations

Example # 1A

In Example # 1A, we have the “message” method that is meant to handle any request to the “#/message/:text” route. While this method works as intended, we instantiate the the “MessageView” class each and every time that route is requested. There is no reason to instantiate that class more than once, and from a performance standpoint, this code is inefficient.

Example # 1B

In Example # 1B, we’ve fixed the instantiation problem by leveraging the “initialize” method. If you remember from the article: “Getting Started with Backbone.js Routes – Part IV: Configuring an Initialization Function”, the “initialize” method only executes once. This is a perfect place to handle setup tasks for views. In Example # 1B, we instantiate the “MessageView” constructor. But, instead of assigning the newly instantiated object to a variable, we assign it to “this”, which is the instance of the “AppRouter” constructor. The reason we do this is because we will need access to that instance object from the “message” method.

Then, in the “message” method, we reference that instance object twice: when setting its “options.message” property and then when calling its “render” method. Both of those actions happen every time the “#/message/:text” route is requested.

Example # 2A

In Example # 2A, we can see the other problem with our code: we mix JavaScript in with our HTML. While this does work, but it is not the most efficient way to go, and we are mixing presentation with data. We will fix this by using Handlebars.js.

Example # 2B

In Example # 2B, we have replaced our “template” method with a call to the Handlebars.compile method. We pass it our string of HTML with one small but important change: the double-curly-braces templating syntax: {{message}}. A discussion of JavaScript templating is beyond the scope of this article, but it is important to note that by using Mustache.js (or a similar templating library), we do not need to mix-in JavaScript with the HTML string we pass to the Handlebars.compile method. The double-curly-braces templating syntax: {{message}} safely retrieves the data that we reference.

Example # 3

In Example # 3, we have the full code for our working example. Visually there is nothing going on in Example # 3 that you have not seen already in an earlier article. But if you look at the page source, you’ll see that there is a dramatic difference in how we go about instantiating the MessageView constructor, as well as how we reference the data in our view’s “template” method.


How to Demo:

This example will not appear to work any differently from the previous article’s examples. The important thing to note is what is going on under the hood. Take a look at the JavaScript file for Example # 3, so you can see that we have put the techniques discussed into action.


In this article we learned two important optimization techniques for Backbone.js views: instantiating the view constructor only once, and separating the presentation from logic. We discussed the router’s “initialize” method as the best place to instantiate our view constructor, as well as how to use the JavaScript “this” keyword to make that instance object available to other methods in the Router class. We also learned how to leverage Mustache.js for client-side templating.