I love the way how each and every discussion turns into the war of the frameworks. I have worked with BackboneJS and AngularJS quite extensively and have come across most of their short comings in production. So, you dont really have to take this analysis with a grain of salt. I would be happy to take back anything that I have said if it turns out to be wrong. Lets get to the meat of it, then, shall we?

NOTE :  I am not trashing Backbone. It was a great tool earlier and in my opinion, its usefulness has diminished since the introduction of newer frameworks like Angular and Ember.

I know that people in general, still choose Backbone over Angular because it seems to be the safer choice, because you cant find as many X-framework developers as Backbone etc etc.. I am attempting to make an argument that Angular is a better choice in all scenario’s where you would use Backbone. Finding developers and how much you pay them is an organizational choice. But, my attempt here is to prove that, if you have 2 smart developers who have no knowledge of Angular and pick 4-5 Dev’s who know Backbone for a largish project, the investment of learning Angular will pay off in the long run. Less code to write means less code to test means less code to debug means less code to maintain. It also means a lesser page-weight at the end of the day. These are some of the advantages you should not ignore if you are making an objective decision.

Here are the myths and my explanations to counter them.

Backbone is very small / compact.

One of the first points that people quote, when they talk about the advantages of Backbone is its compactness. Its just xKB minified and gzipped. Lets see some stats, shall we?.

Angular ( 1.0.3 ) is 77KB minified. If you include Angular ( just that one file )it WILL work on its own.. It does not depend on anything.. If you include JQuery before Angular, then angular will start using JQuery for DOM manipulation. But, including JQuery is upto you. You dont necessarily have to.

Backbone by itself is around 18KB minified (link). Now add in its dependencies Underscore ( 13.6KB minified – link ) and then we have JQuery ( 93KB minified)  / Zepto ( 25KB minified ) itself ( You cant use Backbone on the client side without one of these! )

To note here, Backbone has a much stronger dependency on JQuery than Angular. Some people might complain that even Angular can use JQuery or people generally tend to include JQuery along with Angular in projects etc etc.. People do, but its not absolutely necessary. A Front End project with Angular can make do without JQuery.

Here is what you get, when you decide to write an application with Backbone as your framework. 5 Classes. Model, View, Events, Collection and Router. And Backbone.Sync  ( but lets leave it out for now ) . Mainly, this is what constitutes Backbone itself. That’s it. These are all Base Classes. When you want any of these functionalities you extend these classes and make use of them.

If you think that this is it, then, you are wrong, again!. There are more things that you would have to add ( depends on what you are building! ) or write yourself! . I have in each scenario shown the additional weight ( in KB ) for each Backbone plugin you need.

Backbone is minimalistic.

Oh, this is the biggest farce in the history of mankind, perhaps second only to the belief that earth is the center of the universe. This is what I usually tell everyone who argues that Backbone is minimalistic and gives them a lot of wriggle space. If the framework doesn’t write the code, YOU have to.

If you have to write the code, you cannot stand on the shoulder of stalwarts / experts in the field. Also the community would have found the best way of doing some repetitive task. If you are an expert, then probably yes, you could. But even if you are an expert, you would be an expert in one particular thing or two. You cant be an expert at everything, which means standing on the shoulder of a collection of experts seems like a sane choice.

Oh well, but you argue “I dont have to write them on my own. I  can stand on the shoulder of stalwarts. Backbone has plugins.. Millions of them. I can choose to include the ones that I want, when I want them“. Hah, Intelligent. Please note that choices have costs associated with them. Each time you need to make a decision, it costs. There is an overhead in making that decision. Choosing Backbone means you have to make a hell lot of decisions, so the cost is high. The interesting question is : What do you gain by having the freedom to make these decisions? Let us see some of the choices you need to make :

1. Application Architecture / Layout Structure / Memory management: 

Backbone is a meta-framework. It provides only the “backbone” and no flesh. This means that you would either have to put in the effort to write your own along with the application or depend on something like Marionette (21KB)  or Chaplin (56KB) or Knockback ( to use Knockout! ) (32KBmin+gzip includes everything except jquery. ). If you don’t use these, then memory management, layout management, application structure, global event bus and such architectural decisions are left to you. You would think that this is good because it gives you more freedom to do whatever you want. I kind of disagree with this.

Just for comparison, in Angular.js, unless you are doing something extremely complex ( which wont happen unless you are writing something really really big! ) you would never have to worry about memory management, layout management or event bus. Its all taken care of for you.

2. Nested Models : 

Did you know that Backbone.Model by itself does not support Nested objects ? What I mean is, say if you have a Registration Form in your site and the form obviously took in the user’s details. How would you represent the user in a model? You would do something like

var userModel = new Backbone.Model.extend({
firstName : "John",
lastName : "Smith"
});

What if for some reason ( or for some other attribute )you wanted to do something like

var userModel = new Backbone.Model.extend({
name :  { first : "John",
          last : "Smith"
        }
});

How does Backbone notify you when something changes? With events. If something changes in the model, it fires a change event. In the first scenario you would do something like

userModel.set("firstName","Tom");

and Backbone would fire a change event, which you can catch as

userModel.on("change:firstName",firstNameChangeHandler);

How would you set the value in the second example? You would think that, you can do something like

userModel.set("name.first","Tom");

But, this is not possible in Backbone. So what you would try next is

userModel.get("name").first = "Tom";

This works for setting the value, but.. No Event is fired in this case, which means that , there is no easy way of notifying your views. This is something you have to fix because of Backbone’s opinion! What is the solution? Well, either you have to patch it and figure out a way of doing this in places where you want it to work by somehow working around and coding around this limitation or use something like NestedModel (2KB minified) or DeepModel or Backbone.Relational (seems to be the most popular solution! 56KB not minified!) or fix it yourself in your code.

The same is pretty simple in angular. You could either do :

$scope.firstName = "John";

or

$scope.name.first = "John";

It just works.

3. Data-binding.

There is no inkling of data-binding in Backbone. You have to wire up your view’s and model’s yourself. This is one of the most common tasks in any application and probably an opinion about this would have helped Backbone a LOT. Without data-binding ( and if you dont choose to implement a plugin or include one ), here is how you would do it for each view element <–> model binding.

var userModel = new Backbone.Model.extend({
    name : { first : "John",
             last : "Smith"
    }
});
var userView = new Backbone.View.extend({
    events : {
        "change input#firstName" : "changeFirstNameHandler"
    },
    initialize : function(options){
        //write initialization here.
        this.firstNameInput = this.$("#firstName");
        this.model.on("change:firstName",_.bind(this.onFirstNameChange,this));
    },
    changeFirstNameHandler : function(event){
        this.model.set("firstName",this.firstNameInput.val());
    },
    onFirstNameChange : function(){
        this.firstNameInput.val(this.model.get("firstName"));
    }
});

Note that, you will have to do this ( or something similiar for each binding you need… ) or use one of the data-binding plugin’s for Backbone. Your options in plugins are ModelBinder (11.1kb )/ CollectionBinder (5.5kb ) or Backbone.stickit ( 3KB ) ( Note : this does not have a solution for collection’s ).

Do I need to talk about data-binding in Angular? I guess not. If you dont know about it, check out Angularjs’s home page.

4. Non-Restful Backend : 

Backbone is meant for Restful backend’s. The idea behind backbone is that for each end-point on the backend you create an associated model on the front-end and you create, read,update and delete the resource at the end point using Backbone.Model. This is one of the strongest opinions Backbone has. Unless you are building an app that is dealing with a Restful backend that uses the http verb’s appropriately, you are in for some pain here. If you are not working with a text book defined Restful backend  - be ready to do a lot of tweaks and overrides to the Backbone.sync. You could technically use $.ajax but there is no clear cut place to encapsulate it, which is why most times using it feels like a hack.

Angular has $http which you can use to do anything you want – not just Restful. To make restful easier, angular has ngResource which is an additional file that you need to add ( 16KB min ). So it has its cost, but you can choose to not use it and use $http directly. Its easy either ways.

5. Validation.

This is, in my opinion, related to binding. But, to be fair towards Backbone, it does expose a function in the model to do validations. Ofcourse, like everything else in Backbone you have to write the logic there yourself ( which is fine in this regard! ) but the lack of binding’s irk’s us here as well. So, once again, its either, implement your own or pick and choose from Backbone.validation( 8.2KB min ) or Backbone.validations ( 9.5 unminified ) or Backbone.validator (8.2 non-minified) or any of the other ones you can find.

Angular includes validation, its built in and it has a few validations already implemented like email, max-length, min-length, required etc. If you want some other custom validations you can write your own or use this. ( Note :  You dont have to include the whole Angular-UI if you want to get just validation! This is the beauty of Angular. Everything is soo modularized that you can just take what you want and its extremely easy to pick that out. If you just pick out the ui-validate directive, then its just around ~20 lines of code so I wont bother mentioning the size!).

5. Templating.

A custom templating solution is not an absolute must for Backbone but generally people choose one over underscore’s default templating engine. Most commonly used templating solutions are Handlebars (60 unminified  - This is the templating engine used by emberjs and sproutcore!) / Mustache ( 15.6 unmini ) / Dustjs ( 25.8 mini ). If you dont include any of these templating engine’s and prefer to choose underscore over them, then you have no additional overhead in terms of file size but still you have to make that choice and that choice has a cost. The cost of deciding it.

Angular does not need any templating engine. It uses the most famous templating engine in the world  ( HTML ) by extending its vocabulary wherever necessary. Not just that, it converts your HTML into a DSL which also makes it easy for people to understand it.

Backbone is not opinionated.

Even if you use Backbone you cant do whatever you want and if you do it, then using Backbone seems pointless because, at its core, Backbone IS opinionated. You have to extend Backbone.Model and you have to extend Backbone.View.This IS an opinion as to how you should break up your views and how you should organize your Models. Additionally, I have already covered earlier some of the opinions that Backbone forces on you.

Angular is opinionated. It does not do any claims to be otherwise. There is an “Angular way” of doing things. One of the best is NO DOM MANIPULATION IN CONTROLLERS. Remember that, and all the rest will fall in place automatically.

Backbone has plugins.

This is true. There are quite a few plugins for Backbone, some of which I have already mentioned earlier. For each specific task you need to do, you pick the relevant plugin and use it. The thing with a plugin model is that most of these plugins are at different states of production. The thing you are not aware of at the outset is that, do any two of these plugins work with each other? If you are choosing one of these plugins for a major task ( lets say one of the tasks I mentioned earlier! ) that is a pretty big decision in terms of your architecture. It changes the way you write your code. What is the support level for this plugin? What is the amount of test’s that this plugin has? How is the community behind this plugin? Do a lot of people in the wild know about it / know how to use it? One of the things I have found is that, though people have generally flocked towards Backbone, due to the very nature of people who flock towards it, there is no general consensus of how to achieve a particular task which leads to fragmentation of brain mass, which leads to paltry support at best in case of most plugins. Backbone has a wiki which lists a few of the popular plugin’s.

Most of what you want is already provided by Angular. So, there are very few plugins. If you want something that is not already natively supported by Angular then check out Angular-UI. It has a pretty good list of directives ( the plugins of angular world!) and perhaps a few services and filters too. Like I mentioned earlier, you dont have to include everything from that library ( and probably should not too.. ). Only include the code necessary for the directive you want into your project.

Angular Shortfall.

To be fair, the only scenario where Angular has no solution natively is animating view transitions. Backbone does not have an opinion here either. But since it relies on JQuery for DOM manipulation it can use animations as a bonus. If you want animations in Angular, you would have to implement one, use jquery ( or its animation engine ) or pick some other animation library like greensock. Even then its not a trivial task. But people have done it ( see here and here )

Some shortfalls of Angular : 

1. Angular requires a deeper knowledge of computer science than most other frameworks. You need to understand the DOM at the node level, to understand angular properly while most other frameworks are happy to let you abstract that away at the level of selectors.

2. DI, services, no DOM manipulation anywhere other than directives, directives, filters are all new concepts to client side dev’s. Its all magic sometimes.

3. Form validation framework of angular is not perfect yet. It still needs some tweaks. Its almost there ( 90% ) but there is that 10% that is still not there yet.

4. No transitions / animations..yet… Its coming in the very near future. Angular now has support for animations (link).

5. Writing directives is not easy. Its the most complex part of writing Angular code.

Conclusion :

Here is an analogy. Starting a project is like being at sea. Your job is to get to land, not to complete the task of swimming. The difference between Angular and Backbone is the difference between a Motor Boat and a Life Jacket. A Life Jacket is great. It will perhaps aid you in swimming and probably protect you from drowning. On the other hand, a Motor Boat? Do you see the difference? Yes, if you have a Motor Boat and no Life Jacket then you have the fear of drowning, but, that’s only if you cant swim when the motor boat stops working for some reason. Its upto you to choose, whether you want a Life Jacket and swim all the way to the shore or use a Motor Boat and ride to it.