Like his JavaScript language CoffeeScript, Jeremy Ashkenas’s Backbone JS has quickly become one of the leading choices for building scalable, well-designed web applications using JavaScript. It’s by no means the only player in town, but I’ll list 5 reasons why it’s a great choice for building a solid MV* based web application in your front end.
It seems these days that as it quickly became the norm with Flash when the Flash Player became ubiquitous and it was paired with ActionScript 2 to power richly scripted Flash applications, web site design is realizing a parametric shift in philosophy as well. Clean well-structured code wins over messy monolithic JS files containing hundreds of random objects and functions. Unmaintainable last minute UI solutions driven by the well-worn “we had to do it like this to deliver on time” excuses are being replaced by intelligent thought through code design and architectural decisions. As someone who’s been coding JavaScript since the days of Netscape 2.0 (and please don’t call me a web tech dinosaur because I really hate that), it’s a highly welcomed and long overdue change.
With the expanding speed and power of modern HTML rendering engines and faster and more powerful JavaScript interpreters, web applications are starting to emerge as the solution to leveraging the power and speed of RESTful services to minimize the client payload and speed up the general web experience.
Backbone JS is one of the libraries riding the leading edge of this revolution and as such, here are five reasons I’ve found as to why it’s one of the best options for developing powerful and scalable front end applications.
Built on JQuery
While some other JS frameworks are self-contained solutions unto themselves, Backbone leverages the power of JQuery to power some of its own internal functionality.
JQuery, if you happen to live in an entirely different universe, is a cross-browser, cross-platform JavaScript library designed to streamline the development of client side scripting code. In short, it takes a whole lot of ugly JavaScript code necessary to run your site seamlessly across all browsers and helps you write a more streamlined and elegant set of cross browser complaint routines more easily. It can literally save developers countless hours of headaches trying to figure out a solution to a single problem and then adapt it across many sometime highly incompatible browsers (yes were all still looking at you IE).
While the feature wars are coming to a merciful end in favor of speed and performance, legacy versions of the browsers still contain numerous gotchas and features that usually would require the time to implement and test specific hacks and workarounds. JQuery, however, has come to the rescue. It does the heavy lifting. You just call the functions you need and get on with what you need to do.
BackboneJS uses JQuery where it deems fit which simply means you can use JQuery just as you would in any other development project without any fear of conflict. You won’t need to worry about using JQuery’s noConflict() mode either. And thanks to projects like RequireJS, you can confidently pair it along with other libraries and solutions if need be without polluting the global namespaces. That in and of itself is a big plus in favor of Backbone for me as there’s rarely ever a chance that you can lock down to just one single solution for every requirement.
If having a front end tool that relies on JQuery makes you a bit squeamish, there are also efforts out there in Github to provide extensions to Backbone that remove the JQuery dependency altogether. So you really can have it either way.
Low barrier of entry
For developers like me who have been working with MVC development for the better part of the last 6-7 years, Backbone’s philosophy of separating the management of requests (controller), handling of data (model) and presentation of content (views) is a natural fit to technologies I’ve used before such as CodeIgniter and Ruby on Rails. Where Backbone differs from these solutions is in how it specifically handles that separation, and the way it does was surprisingly welcome to me.
In Backbone, there is no concept of a fixed controller. For example, there is no Backbone.Controller class. Backbone use URL Routing to handle client navigation requests and send them to the appropriate handler function and View classes serve as the means to manage requests and present the appropriate response. While compared to rich server side programming languages like PHP and Ruby which live on a server and can be loaded and executed without having to worry about HTTP data transfer, this is a bit of an over-simplified solution. For a client-side scripting language like JavaScript, that has to be delivered over the web time and time again, it’s pretty streamlined and elegant way to handle managing client requests and keeping everything within a single web page.
The Models and Collections philosophy is also very straightforward. Backbone Models represent a single contained data record of keys and values and Collections are simply a collection of related Models. So if you have a User Model that contains a name, address, email and phone number, the related Users Collection contains multiple copies of that User Model. Binding Models to views and updating views when the data in that Model changes is also very straightforward.
Simple Example:
var userModel = Backbone.Model.extend( {
defaults: {
name: "",
address: "",
email: ""
}
});
var userView = Backbone.View.extend({
el: '#content',
initialize: function(){
_.bindAll(this, "render");
this.model.bind('change', this.render);
},
render: function() {
this.$el.empty();
var template = _.template('
Name: <%= name %>
Address: <%= address %>
E-mail: <%= email %>
');
this.$el.html(template(this.model.toJSON()));
}
});
$(function(){
var theModel = new userModel();
var view = new userView({model: theModel});
theModel.set({name: 'Jeff Fox', address: '123 AnyStreet', email: 'me@myhost.com'});
});
Once you master these core concepts, you can get off and running with building your backbone app as big or small as you need to.
Flexible application design
One of my biggest personal pet peeves with application and development frameworks are those that lock you into a very specific way of doing things. There’s the frameworks way or there’s the door so to speak. I also deplore solutions that require everything to be named using the framework name itself. The PHPSeagull framework comes to mind as every resource that needed to be loaded and developed within that framework was called; you guessed it, PHPSeagull something. What if I change my mind and want to migrate to a new framework? Everything’s tied to old framework.
What made me adopt and really latch onto the PHP Framework CodeIgniter was its transparent design in this regard. Nowhere in a CodeIgniter application do you ever call anything named CodeIgniter (unless YOU the developer specifically put it there that is).
Such is the way with Backbone. While when creating Models., Collections and Views you reference the Backbone library and choose what object you want to extend (more on that later), nowhere in your code are you constantly referencing Backbone this or Backbone that. You use JQuery, you can reference Underscore for helper function or you use your own code and naming conventions.
And unlike some other framework solutions, how you choose to organize and boilerplate your application is entirely up to you. So for solutions where I want a quick down and dirty build to handle maybe 2-3 views and a single REST service, I can throw together a single JS file containing all my code and run it almost instantly (see the simple example above again). Try to do that with some other solutions. You’ll quickly run into a couple obstacles, headaches and some frustration.
Figuring out just what kind of boilerplate you want to setup is half the fun of starting a Backbone project and one reason why it can adapt to just about any type of web app requirement. And once you have it setup, reusing it across other applications you’ll create gives you a standard starting point for your team to build off of.
Choose your templating solution
As the last bullet point illustrated, Backbone gives the developer the power of choice. And another area that this repeats itself is in the way to decide to develop you view solution.
Unlike some frameworks and solutions that lock you into using a specific templating solution (or jumping through a number of hoops to switch to another), Backbone doesn’t care in anyway how you arrange your templating solution. The Backbone View class has a simple template function to apply an HTML template to the view element, but how you go about getting that created and compiled with your data is entirely up to you.
Conveniently, Backbone’s companion library Underscore JS includes a fast and effective templating solution built in. But it’s by no means the only way to go. If you want to use more of logic-less solutions like Handlebars, you’re free to switch. Want to use pre-complied Dust JS templates? No problem. Maybe you feel the options out there are not to your liking and you want to roll your own custom solution. Go for it! Backbone does not place any limits on you in this regards.
Scalability
One of the biggest (and least thought through) issues with web application development is future scalability. Given the introductory set of requirements that are used to create your web app and the progression (and addition) of new or revised requirements over time, being able to scale your web app over time is a critical consideration. Backbone provides flexibility in this regard.
If you want to modularize your code and refactor it, Backbone has the flexibility to allow you to do this. Maybe you want to implement a more modular type of architecture such as Marionette. Once again, backbone is very flexible. A little refactoring will go a long way to let you do this. Or maybe you want to create a single front end single page web app for one workflow on your site, but marry traditional HTML templates and layout with dynamic Backbone driven modules that access RESTful services within those pages. Once again, Backbone can handle this scenario.
Because Backbone leaves the larger architectural questions up to the developer (or hopefully a highly skilled front end architectural resource), the sky is the limit for how and where Backbone is utilized. And because you’re not locked into a specific architecture, you have flexibility to grow and expand over time. A great example might be repackaging some key components of your web application to reuse in other projects. I’ve found that with a few changes to the internal plumbing (regrouping views and refactoring some code in your app router); you can shift and reuse the same code across different related applications. For IT directors and project managers, that’s a huge upsell in terms of maintainability and maintaining a DRY philosophy. That and it doesn’t hurt when trying to keep your current and future capital project budgets on target.
Addition points
There are still more benefits that I’ve come across that I’ll simply bullet point here (though I reserve the right to follow up again at some point with another list if I so choose).
- Dependency Injection – Inject dependencies at run time to foster loose coupling of resources throughout the app lifecycle.
- Interoperability – Use Backbone with JQuery AND other libraries is you so choose. Both JQuery and backbone support releasing their global variables so you can run separate tools OR separate instances of Backbone together if need be.
- Flexible data binding. The simple example above illustrates this point though there are ways to really expand on this.
- “One-to-many” relationship between models and views. Attach a model to multiple views and update them all automatically when the model changes.
- Hackability – There are many ways to override Backbones default functionality to adapt it to your needs. The Backbone.sync method override is just one example of this.
Others using (and liking) Backbone JS
But don’t take my word for it. The guys over at Planbox.com used Backbone JS and had some good things to say about it as well.
You can do a lot worse to design and deploy your web site and web applications that to implement a flexible and powerful MV* type design. Backbone JS is one of the leading and flexible tools when it comes to adopting this type of architectural and build philosophy. What do you like (or maybe dislike) about Backbone? Happy Coding!
