Backbone.js – A new approach to writing JavaScript at LiveRamp


Learn from our challenges and triumphs as our talented engineering team offers insights for discussion and sharing.

Backbone.js – A new approach to writing JavaScript at LiveRamp


Here at LiveRamp we help businesses bring their offline data online. In order to streamline that process, we have built an array of web applications allowing customers to upload their files, import data from files, segment their lists, etc. Most of these applications are client-rich, involving a fair amount of JavaScript. Up until now, we’ve implemented most of our JavaScript code using piles of event handlers with DOM selectors, spread all over the place across multiple files. That gets fairly complicated when multiple events need to be triggered on a UI action, for example validating a new entry, persisting it, updating multiple UI elements, etc. More often than not, our view code becomes cluttered and hard to read with no separation between code handling the data and code for updating the views.

Our use case

One of the applications we recently built for our customers is the Segmentation Console which allows them to create sublists of their consumers, for example finding everyone in the age range 25-34 from California. The application is fairly simple, allowing for logical operations like ‘equal to’, ‘greater than’, and ‘less than’ to define rules. Customers can also create complex definitions by combining these rules using ‘or’s and ‘and’s.

A few of the requirements for the application were –

  • to validate the UI actions, for example, a customer shouldn’t be able to select the ‘greater than’ operator for a string value.
  • to send the segmentation rule (e.g. state == ‘CA’) or combination of rules to the server to return the count of people matching the rule and update the UI.
  • to update a summary view with a list of all segments etc.

The pains with traditional spaghetti-like JavaScript and the requirements with this new application motivated us to look into something more structured and more modular; some framework where we wouldn’t have to write event handling code over and over again.

Why Backbone.js?

Backbone.js is a very simple and lightweight JavaScript library based on the MVC architecture, allowing models to be bound with views via events. With Backbone.js, data is wrapped into models which makes it easy to perform operations like creating new model instances, deleting, validating and syncing to the server. Multiple views can listen to changes in models or collections of models allowing the view code to be separate and modular.

We looked into a variety of MVC based JavaScript libraries but picked Backbone.js mainly for the barebone nature of the framework given the simple requirements of our use case. The few conventions of Backbone.js help building simple web applications while keeping the code structured, readable and maintainable. At the same time, the framework doesn’t get in your way when doing something more complex.


We built our Segmentation Console with Backbone.js and were super delighted with the framework and life was good. However, things got a bit complicated when we decided to revamp our Importer UI to use Backbone.js. The Importer UI is a web application that we use internally to read customer files and configure how we want to import those files. This is a complex application allowing for more user interactions and involving many nested levels of models. Soon we realized that the lack of conventions in Backbone.js may be a boon for simple applications, but you start missing those as soon as your application requires more than a handful of models and views.

One of the features we wished Backbone.js provided was better handling of subviews. Every time we needed a view to render a collection of models, we found ourselves taking care of initialization, rendering and destruction of the child views. For example, when removing an item from a list, we’d have to iterate through the list of subviews to find and close the view associated with the appropriate item. This is what our RuleCollectionView looks like –


var RuleCollectionView = Backbone.View.extend({
  initialize : function() {
    this.ruleViews = [];


  removeRule : function(removedModel) {
    var newRuleViews = [];
    _(this.ruleViews).each(function(ruleView) {
      if(ruleView.model !== removedModel) {
    this.ruleViews = newRuleViews;




Backbone.js also doesn’t natively support polymorphic collections. In order to have a collection containing models of different types, you need to create a wrapper model which is a union of all the different types, only one of which can be initialized at any point.

How do we feel about Backbone.js?

One of the takeaways from using Backbone.js for two completely different applications in terms of size and complexity, is that the framework works great for smaller applications, but doesn’t scale readily for larger ones. It is great because of the lack of assumptions it makes, but it does mean the developers have to decide how to design and implement various features themselves. It provides a great starting point for building structured client applications, but leaves much of the architecture, view and model management to the developers. That said, using Backbone.js has definitely been a step in the right direction for us at LiveRamp for writing applications using a lot of JavaScript, and we definitely recommend checking it out. Our next steps include looking at some of the other libraries built on top of Backbone.js like Marionette which promises to fill in the gaps. For example, Marionette has built-in view management, memory management and event cleanup.