Backbonejs vs Angularjs : Demystifying the myths

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 scenarios 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 Devs 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.

Angular size

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 necessaryA 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 users 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 views and models 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 plugins 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 collections ).

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 backends. 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 verbs 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 bindings irks 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 engines 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 tests 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 plugins.

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 devs. 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.

You might want to checkout some common AngularJS confusion points or perhaps a few things that are probably the Do’s and Dont’s in Angular ? Or if you are up for it, how about another comparison but this time between Angular and KnockoutJS?

142 comments on “Backbonejs vs Angularjs : Demystifying the myths

  1. Great article !
    I agree with what you wrote since I’ve experienced both frameworks. I definitively chose the motor boat :-) 

  2. You re all wrong.

    Criticising a screwdriver because you can put a nail with it and so declaring a hammer is better than a screwdriver for any tasks for everyone… so wrong man.

    Angular is better for you, for your project, for your mind, for your dev level. Make your article sound like this, and not like your comparing objectively and technically those both FW, otherwise BB win .

    • Hey G-rom,

      Angular and BB are not for different set’s of people i.e I am not prescribing a screw-driver to people who wish to use a hammer or vice versa..They are competing frameworks and are actually competing for the same mind share. So, its not really a comparison of apples and oranges..Its more like comparing apple and android :)

      I attempted my best to keep things objective. This WAS my best objective assessment. You mentioned that “otherwise BB win”. I have heard this argument before, multiple times and this article was a response to those arguments out of frustration. I would like to read and article pointing out the places where BB win’s.

      • My last sentence “otherwise BB win” was between “troll” tags. Obviously tags are removed. Next time I will try [troll] [/troll].

        I disagree on the fact you compared like apple and android.

        This article is really like comparing tomatoes and red pepper. They have the same colour, the same size, but definitely not the same flavour.

        Another example : comparing Flask and CherryPy in Python backend. If someone one day ask me to choose between those, I will ask before: for what purpose? Because depending on the context and purpose I will not choose the same. They both are very good, yet they does not feet in the same paradigm.

        This is exactly the same for BB and Angular. Like Flask and CherryPy they both are in the same language, they both are for front-end, etc, but they clearly does not respond to the same demand.

        It is a shame you cannot see that, it kind of make you a bad chooser. Developing things is making choice, from the top beginning.

        • Could you please explain where / what scenario BB fits better ? Describe the scenario? I might be wrong here, but its my assumption and belief that whatever BB can do Angular can do and better.

          If we are talking about client side development, then Angular surely beats Backbone, in all domains. If I was comparing a screw-driver to a hammer then there will be atleast one scenario where a screw-driver will beat the hammer isnt it? I am looking for that one scenario!!

          The only scenario which I can think of where BB can outdo Angular is on the server side. BB can be used on the server side, Angular cant.

          • One simple example, we have this use case here. We want i18n in our template, so we are using handlebars with our internal i18n processes and libs.

            All my other example will be based on that:
            Angular is powerful but big and monolithic, whereas BB is thin but let you choose the way who want to use it. If all in Angular feet your needs, go for it. But if at some point, I may be blocked by the choices Angular made for you… ouch.

            Here we need this flexibility. We love making choices and built our own solution because things are moving a lot and we have to able to change and responding quickly.

            On some other condition I may have choose Angular, because it is also a good framework, but not for my current need.

        • I believe wordpress has reached its limits on comment depth.. So I am going to attempt to answer you here. i18n is possible in angular too.. in your template. ng-include is a way of including any template you want.. dynamically. If you are interested in knowing more and how you could achieve that let me know.

          No framework is going to fit your needs completely. Ever. I know that. There is a reason why I chose an analogy between a life-jacket and a motor boat. A motor boat is a complex machine while a life jacket is simple. No matter what you try, you dont get the speed of a motor boat with a life jacket. In the middle of your journey, the motor boat might stop working. I understand. But that is why you should have learnt to swim.

          Lets say you are in the middle of the sea and I offer you a choice between a motor boat and a life jacket. You only get to choose one! Would you say, “I wont choose a motor boat, because its not flexible, its complex to understand and has a 1000 moving parts and I dont understand all of them, so I will choose the life jacket” ?

          • Sorry raj but your analogy is too oriented so I choose to not respond to this obvious question that wait an obvious question.

            I’m French, and the way we do i18n here is just not possible with Agular for now.

            Another example. The way Agular choose to bind controller and view is like view know some of the controller.
            So let say I have quite a team here. With a Web Designer. It is not a front dev, and I do not want him to know JS front dev.
            So I prefer when it’s the controller that know the view, or view that know the template in MVT, and also when multiple controllers can re-use views. Welcome Backbone. Both made different choices for this strong dependence, I’m not saying one is right, the other is bad. Just one fits the need.

            Anyway, all this to they that I keep thinking you re trashing BB the wrong way, comparing with Angular as if Angular did make the right choice but not BB.
            It’s really not like you can choose Angular any times and BB just at some point, or you really are missing some needs. It’s kind of remind me when I was a Java dev and all people swear only by Spring or Struts…

            I prefer to stand with they both good, with completely different architecture choices, and that is really good for all front-end devs who could choose the right (good) tools for the right job, for any job, thanks to all those FW, and not being stuck with one wobbly solution.

            Nice talk, see you around.

            PS : some refs you should read, http://coenraets.org/blog/2012/02/sample-application-with-angular-js/
            http://stackoverflow.com/questions/11458436/angular-js-backbone-js-or-which-has-better-performance

          • Gotta agree with G-rom here… You claim to be objective, but any objectivity you begin with disappears really quick.

            You can literally hear you foaming at the mouth w/anger when talking “objectively” about how much you hate backbone… You literally forget to compare elements of angular, because you get so set on elaborating on why backbone’s approach sucks (or get caught up in phrases like “non-opinionated” which clearly bother you).

            http://addyosmani.com/blog/short-musings-on-javascript-mv-tech-stacks/ <- that's a much better example of "objective" comparison between JS MV* frameworks.

            Addy Osmani likes, reccomends and programs using both Backbone and Angular. But then again, he works for Google, and is probably one of the most well respected FE Dev's out there at the moment. While you… Who are you again?

          • I am an end-developer… a developer who is working here in the trenches as opposed to Addy who would only be experimenting with Angular or Backbone or such.. I am a ‘user’ of these so called frameworks.. I am going to shout as loud as I can to see if my voice can be heard over the giants.. If it can, I will be glad.. But I will not be dissuaded from making an effort..

            Instead of making such base comments about the tone of my post, you could perhaps be smart and show some of the shortcomings of what I am writing? Show me the instances and places where Backbone outdoes Angular perhaps?

        • > I’m French, and the way we do i18n here is just not possible with Agular for now.

          Nice argument. Too strong. Do you plan to describe your way of using i18n?

          > The way Agular choose to bind controller and view is like view know some of the controller.
          > …
          > So I prefer when it’s the controller that know the view, or view that know the template in MVT, and also when multiple controllers can re-use views.

          Do you think that declarative style for frontend interface is worse that imperative style?

          If no, how your controller will use views?

          If yes, I think your position is “I don’t like declarative code, I like imperative code”. It is not bad. It is more clearly and explicitly.

        • Out of curiosity to G-rom, as I am just getting started with Python.
          What are the typical use-cases which match Flask vs CherryPy and vice-versa ?

  3. Just what I’ve been telling people for a while now, though I will say that people using Backbone is better than them not using anything.

    Though I will say I don’t like the way Angular has extended HTML. I would prefer if there was some preprocessing that could change it to pure HTML on the server side (perhaps there is, I haven’t used it much).

    One thing I don’t like is that declaring binding always seems to come down to putting the bindings in a template, which means the bindings are declared directly with the HTML. I’d prefer that the bindings were declared using selectors (I wrote https://github.com/rhysbrettbowen/PlastronJS which does this), usually I bind in the code and use class names. This means that the logic stays in the code, not in the templates. Also for listing out a collection the logic stays in the code (there is an autolist function that will write out each component for you). Each element that should be listed is a component in it’s own right (even if it is as simple as just a template). This means it’s easier to swap out different ways of displaying an element in a list rather than having to change the template for the master control.

    I like what Angular are doing and agree with a lot of it, but think they might have taken things a step too far.

    • Thank you for responding. I agree with you. Backbone is 100% better than not using anything at all. It provides structure, it provides a separation of concerns.

      Angular is a client-side MVC. It cannot change anything on the server side. On a side note, pure HTML ( this is a mythological being.. Its a language!!). If someone is writing in javascript or java and I insist that they keep it to pure javascript or java does it mean that they have to stick with the functions and objects that are pre-defined and you cant create / extend it to create new ones – How would it seem? This argument for pure HTML seems the same to me.

      In application there are two kinds of logic. View logic and Business logic. View logic is the logic that defines stuff like show the view, hide the view etc.. You probably know what Business Logic is. What you are insisting for is to separate the view ( html ) from the view logic and business logic. What angular and similiar frameworks insist for is to separate the view logic and business logic. I believe that the view logic should stay with the view.. Or else it feels like a hack. We have gotten accustomed to this hacky way of doing things soo long that even when the right way comes around we dont recognize it.

      • “On a side note, pure HTML ( this is a mythological being.. Its a language!!). If someone is writing in javascript or java and I insist that they keep it to pure javascript or java does it mean that they have to stick with the functions and objects that are pre-defined and you cant create / extend it to create new ones – How would it seem? This argument for pure HTML seems the same to me.”

        I do not completely agree with the above statement. When binding is specified in the template, there is a tight coupling between the template and the controller. That is, when bindings are declared in the HTML, you need to look at two places 1. the template and 2. the controller to determine the co-relation as opposed to just the controller. This will become less productive when there are lots of bindings in a template, there could be lots of back and forth between two files, that’s probably the very reason Unobtrusive got very popular. Also if the click handler name changes, it has to be changed in every template that uses it.

      • In AngularJS, when binding is specified in the template, there is a tight coupling between the template and the controller. That is, when bindings are declared in the HTML, you need to look at two places 1. the template and 2. the controller to determine the co-relation as opposed to just the controller. This will become less productive when there are lots of bindings in a template, there could be lots of back and forth between two files, that’s probably the very reason Unobtrusive got very popular. Also if the click handler name changes, it has to be changed in every template that uses it.

        • I dont see the point of separating out the binding and the template or why the template should be totally un-aware of the logic around it. You are right about the fact that if the name of the click handler changes, all the template which use it will have to change. But, let us consider this : What is the probability of you re-using a controller? You Can re-use it.. But would you write one controller and use it with 10 different templates? Is that a possibility? And once you have written a click handler , say it is the click handler of an edit button.. Why would you go about renaming it? Having the flexibility to do so is great.. but at what cost?
          On the other hand, with BB or such jquery based framework’s – Your template IS bound to your javascript. The designer’s in the team do not have the freedom to move around DOM elements ( unless you provide an id to all elements and refer them with id’s only! ). I have seen this happen many time in previous projects. Its not always convenient to have id’s only. So we go for classes and sometimes it has to be finding elements within a particular element. This binds the structure of the html to the code.. Which is worse…much much worse in my opinion because now both your template and logic ( because you dont separate out the business logic from the behaviour logic! ) are tightly coupled and you cannot change one without touching the other.. Also the cognitive load, required to do this is huuuuuge.. Because your brain has to hold the structure of markup and assess the changes… This is not easy… not always..

    • I also coped some time with MVC frameworks, and found that no one is suitable to build business applications, because they all lack data service part integrated with the framework.
      The use of the loop control (like the foreach loops) in the templates clutters UI and couples logic with it.
      Previously i used Microsoft Silverlight to create LOB applications, and it fits very good for this purpose. Its MVVM databindings style is clean. But all is now shifting toward HTML 5, and i had to create my own framework – jRIApp, that fits very well for datacentric SPAs.
      i published it under MIT license on GitHub jRIApp
      So anyone can use it or at least try it, and compare with other frameworks to see the difference.
      It was specially designed to build LOB applications like it is done in Silverlight with WCF RIA services. It is based on MVVM design pattern and also has integrated data service part.
      You can watch demo on youtube for Single Page Application
      Demo

      • It seems like you are building another GWT. If you want GWT, use that. It works perfectly well, and has tons of features and support. Plus, your “jRIAApp” is Windows only, meaning that it severely limits deployment. These days, Windows means desktops, not servers.

        AngularJS includes only client side code. So it includes the ngResource REST connector, it doesn’t include the server side REST service.

    • I understand where you are coming from. When I saw Angular for the first time, I thought “You aren’t supposed to mix handlers in the html. Don’t these guys understand MVC 101?” But then I did a little TODO list in Angular. It was a wonderful feeling. It felt more creating than satisfying a compiler. My friend challenged me to rewrite it all in jQuery in proper jQuery style. We rewrote it together. It took 3 times longer which is strange because there were two of us, we both knew jQuery well, and the design issues were already ironed out. Remember that it was my first Angular attempt, and it blew the jQuery version away in everyway.

      We thought maybe it was a toy project that artificially gave an unfair advantage to Angular, so we wrote a add-on product using Angular and Bootstrap. We wrote original product in jQuery. We are 90% done. Where the two products overlap features, jQuery has 100 lines to Angular’s 1–absolutely true for my complex app. The original took 2160 hours. The add on has taken only 24 hours so far. That is crazy! We keep thinking we should wake up from this dream. (Yeah, I know I’m comparing apples with apple trees. I don’t have the luxury of rewriting everything for true comparison.)

      My point is that it is easy to justify our choices by patterns, best practices, heuristics, etc. I used to say things like I prefer to bind using selectors, but that was a false goal. I’d prefer to build my apps faster, to make them easier to read, maintain, and test. When you start to do things the Angular way, you start to notice how you cheated before. Like you I usually would bind in the code and use class names. Class names are for css, but you end up cheating and using them as hooks for all kinds behavior. That’s something we identified during the TODO list rewrite. We spent far too much time mucking about creating classes and id’s so we could use selectors. The extra crap put in the html was not very descriptive and it really is indirect code. You have to go somewhere else to see what was bound to it. So I much prefer Angular’s mucking about with directives in the html than mucking about with selectors. Plus, Angular did help me see the difference between presentation logic and business logic. Presentation logic is fine in the presentation. Business logic belongs in controller. Always before, presentation logic ended up in controller and I’d defend it saying it the MVC way.

      That being said, I absolutely disagree with new element directives like and . What real html do those turn into? The attribute directives are golden. They don’t hide the html, they just enhance it. You said it: they went too far, especially when extending html tags.

      Also, like many, I think I get Angular, and BLAM! I’m stuck. It’s a deep rabbit hole. And then I learn and keep going. Much of it is intuitive and works like magic, some is rocket science. It’s a strange framework. It is simultaneously the easiest/most powerful and the hardest/weird. I still don’t write my own services and directives. I think it’s like Larry Wall said of a good language, “Easy stuff should be easy, and hard stuff should be possible.”

      Right now I’m beating head trying to make jQuery Mobile and AngularJS play nice together. If I fail I’m giving up JQM, not AJS. The more I dig, the more quirks I find in JQM (and this is not my first JQM project). JQM is HIGHLY opinionated and doesn’t play nice with others, but Angular doesn’t help any to make it easy to adapt to JQM.

      I can’t say you’ll have as much fun and success as I have. Maybe our apps differ so you won’t get the same benefits. But you owe to yourself to try it on at least a small real project. You have to experience it.

  4. I totally agree with the “pros and cons” of Backbone, I’m experiencing them for 1 year now everyday, and it hurts me regularly :-)

    The worst thing to my mind, about Backbone, is the fact that it brings some starting of answers to questions, but is not _completely_ answering them on belief of flexibility (routing, data binding, templating, validation).

    I started to look at Angular since 1-2 weeks now and, even if I won’t be able to move from Backbone to Angular on my current project.
    I’m convinced with a lot of things about it, but I would have liked to read more opiniated view on it than you’ve done. In fact, I don’t see any “cons” over Angular, which doesn’t make it look an “objective” view (this is not a criticism, just my POV).

    I would be interested to know how long did you experienced both framework ?

      • My personal POV on what I read (not yet experienced) about Angular, is :
        - DI seems to work like magic : using function parameter names to inject appropriate components sounds really easy/cool but it frightens me a bit
        - I’m not really fan of altering the DOM with new “vocabulary”. (on this topic, I think you should speak about IE compatibility issues in your listing). This is just a feeling I have about it, maybe I’m just a conservative here.
        - Creating custom elements seems, as you said, a real pain, having to integrate html code in custom components, blearg !

        You didn’t answered my question : for how many “working” weeks/monthes have you experienced each framework ? :-)

        • Sorry I missed the how long part. I actually started typing in the comments , deleted everything put it on the main post and missed the how long parts in the transition. :)

          Anyway, I have approximately an year of experience in BB and around 8-10 months in Angular. I could say that my knowledge of Angular and BB is pretty advanced. I know both their internals.

  5. I liked the article.

    I come from a bunch of very large projects implemented with closure tools and everyone used those extensively will confirm that being hard to understand is not the real problem for large projects, the real problem is how fast it can grow and how easy would it be to maintain.

    Recently I wanted to try something new, but pretty much everyone is praising backbone.
    No matter how much tutorials I read I do not find anything new or interesting there nor anything that can aid the development process I already have structured with closure.

    Also recently I have watched the presentations and demos with components/shadow DOM. I think this is exactly what we should do client side to allow for infrastructure for large applications. However this will not be ready for long time and even longed to proper support.

    So I have a question: is there an article or a tutorial that describes the Angular “way” of doing things in details and in such dept as to allow an end user to understand the technical internals of the project? On the surface everyone is writing demos and praise Angular and how much it provides by default. But I do not find in depth explanation on why it does it that way or how exactly it does it. And ready the code might be good but just after you know the concepts behind it, otherwise you get lost.

    So basically – do you think Angular can be used well and as designed to be used without such deep technical understanding of its internals. This is a question asked by a guy that have developed with closure tools for 2 years and I can say that one cannot use closure to its true potential without very good understanding of its internals.

    • I am glad this piqued the interest of someone who comes from a larger framework :)

      Have a look at the AngularJS’s guide section. I would urge you to especially go through the sections for overview, HTML compiler and conceptual overview. If you have not already done the tutorial for Angular, then that is a good place to start. I am planning on writing some tutorial on Angular but it would probably be an in-depth one for people who already know Angular.

      There are currently good in-depth tutorials for Angular. There are some tutorials out there which are pretty good and there are books coming out in the near future. Watch all the video tutorials since each of them will give you some detail or the other that you had missed earlier. You can also look at AngularJS’s official youtube channel.

      I think that no tool can be used well without a deep understanding of its internals. But, angular is designed to help out two different segments of people. 1. People who write code / JS developers. 2. People who are designers who are pretty good with HTML and CSS. If you are working on something trivial and all you need is Angular’s pre-defined directives, angular will work pretty well. If you need someone to write directives ( custom components! ) then its a bit more of a complex process and you will probably need an advanced user to do that. On the other hand, almost anyone with a basic knowledge can use these directives once they are defined. Check out Angular-UI which is a repository of directives which have been already written.

      • Thanks for the response. I have visited the resource already and I skimmed the tutorial.

        I think the biggest challenge will be shifting mental model of how ‘thing X is done’ from one framework to another. Having very large and complex application requires lots of planning and structure and what got my eye on Angular is its directives and basically constructing modules that have representation in the DOM, kind of like in components specs. I would say it will require some time gathering the knowledge to write a complicated widgets as the ones we’ve built with closure. What I am looking for right now is actually ways to control the rendering and life cycle of a component as we are targeting a very specific niche – low memory, low cpu stb devices, where caching and precise control on when and how rendering is happening are essential. Hopefully angular is tweak-able enough to allow us to do our tricks.

        Thanks for the overview and congrats on the great job.

    • It’s a good question. I write SPA’s using ajax to load huge hierarchal json from REST servers and two way bind the json to html. Every page in SPA touches a piece of the central json. It’s a snap. I read that I was doing it wrong by using jQuery’s $getJSON() instead of Angular’s $http.get(). It was awkward but short rewrite because I didn’t understand modules, but that taught me. Then I read that I wasn’t using the power of $http’s promises. Ok, learn about promises. Now I’ve read that I should be using a service called a resource, or write my own resource. Ok, I’m ready to learn more.

      My story has some relevant points to your excellent question.
      1. I would say yes, you can get a lot of power from Angular even if you don’t understand it fully. That’s my situation right now. You will drive yourself crazy if you don’t develop until you understand it all.
      2. You must practice it. I don’t even think it’s possible to understand Angular without practice.
      3. Don’t worry about the zealots who say you are doing it wrong. Make the changes they suggest when you have time.
      4. In my case, the changes were marginally better at best on that project, but what I learned about javascript and design paid off on other projects.
      5. Sometimes the zealots and style police are wrong. Sometimes a little–I said a little, not a lot–sometimes a little code smell is better than the orthodox solution. Hard for some folks to hear, but sometimes the cure is worse than the disease.
      6. Even though I don’t use the full power of Angular, the 25% that I use has blown me away by it’s expressiveness, power, and quick dev. I’m not alone. My whole team with broad web dev experience refuses to do web apps without it anymore.
      7. Practice it with a partner/team. Not only is it easier to learn and get unstuck, but you don’t have to waste time convincing them after you’ve learned it.

  6. Slow and steady never lost the race.

    You make some good points, I don’t have much experience with Angular because
    it does a lot of stuff for me, I don’t like not knowing what’s happening and why at all times
    yes you write a lot of code with BB but in the long run it pays off.

    I will take another look at Angular, great read anyways

    Good job

    • You could sneak a peak and have a look at the internals of angular. It does do a lot of things and a lot of things are magical. But once you understand the magic and how it does it behind the scenes you will feel the elation of having figured out a magicians trick. Using my metaphor : Learning to ride a motorboat is hard, but, at the end pay’s off.
      Slow and steady will only win the race if there is no one else who is faster and steadier. I believe that Angular is faster and steadier.

      • Point taken,
        I will give you this, it’s super easy to get going with Angular
        and I will feel better once I can find the ‘trick’ :)

        Cheers

    • Even though the magic is unsettling–I understand the feeling well–the end result is usually quicker to pick up for a peer than the traditional methods. If nothing else, I suspect the sheer reduction of code helps. When done right, it’s just easier to read and comprehend. Of course mileage will vary. “A ‘good’ programmer can write Fortran in any language.”

  7. Great article ! I agree with you for the Angular part.
    I have no experience with BB but with AngularJS.

    I think that the difference in size (that is calculated in kb) of the frameworks is the last argument to make a choice, especially for big applications.

    The first argument is what it can do compared to what you need to. As you write it so well : “If the framework doesn’t write the code, YOU have to”. (But you have to, only if you need it…). That’s why I think that AngularJS is adapted for medium or large applications. I mean, you don’t need a motor boat to cross a pool ;-)

    A pro for Angular that you’ve not mentioned is the fact that as it is an “All in one” framework, An (good) Angular developper should understand most of projects based on Angular (ok, more or less quickly, depending of code’s quality).

    A “con” (or rather a restraint) for Angular is his learning difficulty. There are several concepts that the developper must well understand and that are not always common in the web environment. An example is DI. It is very powerfull but you have to understand it very well to use it correctly. And It’s not common in web languages (but Symfony 2.0 uses it). Directives are, for me, awesome. It is helping you to write reusable code, to reduce your code and your templates. But, to write good directives you have to understand the process of compiling/linking which is not easy.

    The real con for me is the “one route / one view” relation. When you have complex application with multi-views, Angular By default can’t handle that easily §
    (there is a topic on this problem and a solution that i’ve developped, using the powerfullness of DI : https://groups.google.com/forum/?hl=en&fromgroups=#!topic/angular/ayG1hCUOfX0 )

    When i had to choose the frontend framework for my big project, i run through the doc of all major frameworks. The think that i not liked in BB is the quantity of the code to write for data binding. Just disgusting (for me).

    Vincent

    • Yeah, the one route/one view didn’t work for me either. I think it just comes down to the needs of the app. I like Angular because it’s a buffet. If you’re a carnivore, it’s ok to skip the salad.

  8. Let me start by saying I LOVE Angular and I think I would go nuts building apps the way I had pre-Angular. That being said, I don’t know that I agree with everything in the article. A major point is that Backbone and Angular are not directly comparable. Backbone is extremely basic, and is really just library that gives you MVC. But Backbone along with Rivets.js can produce an app that, on the databinding side, feels very much like an Angular app (Rivets.js data binding is extremely similar to Angular, though I would say even a bit more flexible). Add AMD and you get modules something that feels similar to Angular dependency injection. Those three together give you many of the initial benefits of Angular and remove the boilerplate Backbone code and handle the Backbone event management issue.

    That being said, I would still go with Angular. But the argument changes from a “Backbone has tons of boilerplate” argument to the benefits of a framework vs various libraries wired up to work together. Angular has the advantage that everything is in one package, maintained as one package. You get very opinionated separation of concerns, which can be a huge plus in a multi-developer environment.

    • They are comparable. Their target audience is the same and that is what I wanted to bring out.

      You are right, rivet and Backbone together could perhaps bring out most of the 2 way data-binding things but still what about the rest of the things that you need to do in a non-trivial application. Validation, Nested Models etc. These are important and we will need a good solution that can cater to all these or plugin each piece and pray to God that they behave well when put together. AMD does feel similiar to DI but its not really DI. Using Require for example is not a trivial task and getting its optimizer to work is another thing ( well, not saying it cant be done. Just saying that its no piece of cake!). And then making jasmine work with require?

      The best thing about angular, I think hands down is the separation of DOM manipulation from your application code. This is, if I can say, the single most awesome thing that Angular provides.

  9. Everything here is so true, i just don’t understand devs super paranoic attitude at those library sizes. COME ON it’s 21st century almost 2013, 31kb or 300kb has absoluteley no difference on 3g, don’t get too geeky into these milliseconds – 99% of users is just simple people and they don’t really care whether it is loaded in 0.0456546 second or in 1 second or even 3.

    • You are right about the paranoia in file size, but the point I am trying to prove is that to get the exact functionality that is provided by Angular you need to include all those individual plugins ( which will end up more than Angular’s size when you add them up! ) and still would have to end up writing hell lot of boilerplate code. So, I wanted to leave the reader ( and the people who argue that adding those individual bits is better! ) “What do you gain by doing that?”

    • I would second what Raj says here about size. We ran some stats on Angular and after removing comments the angular.js file is actually only a bit over 6000 lines of code! Pretty amazing they can fit all that functionality into 6000 lines (including jQuery Lite). Min and gzip it and the overall download size becomes quite small.

    • Completely disagree with this, performance is of critical importance and too neglected. He’s right to list out the file sizes. People not only care if a site is sluggish, they’ll ditch it and not return. Amazon, Google etc have found a direct correlation between page load speed and key metrics.

      • Totally agree Jon. File size and site speed are extremely important and it is insane to think that in 21st century this doesn’t matter. This arguments is given only by those people who have never worked on large e-commerce sites like amazon, ebay or google, it clearly hits the business bottom line even in 2013.

    • Too true. Even worse is when we get selectively paranoid. We count every javascript byte to cross the wire on a photo listing app where each thumbnail is a a megabyte.

  10. Great article Raj,
    Can you suggest any resources for understanding the Dom Nodes better? I found some stuff on w3schools but it does not seem comprehensive Computer Science enough.

  11. The only thing I don’t agree with in your article is that writing directives is hard. The docs for directives is hard to read, but writing directives is actually pretty easy.

  12. This is a great blog post. I already have an single page application in mind so I use it in determining which JavaScript framework I will use. I started off using Knockout, but dropped it because it lacks concrete examples on how to create a real single page application (with routing, etc). It was well as a companion to server side applications. I tried include routing libraries like Sammy.js. After a while, I got frustated with having to use a seperate library to do different things. Then I move on to Backbone (mostly because it seems to be the going standard everyone raves about). Contrary to popular opinion, I found Backbone to be an extremely rough experience for me. There are just too many different versions out there with drastic API changes. Many examples and documentation on the Net are out of date. After spending over a week trying to do something I felt should have been simple, I looked for another library. I read up on Ember.js and tried it out. I hit some bumps with it mostly to due poor documentation with little examples. I finally ended up deep diving into Angular for two days straight. I finally was able to get a simple page working (with a RESTful backend) and I am pleased with the results. So far, I think I will stick with Angular. The one common denominator with all these client side frameworks is horrible documentation with little to no examples. Although, I will probably choose Angular overrall, I feel Knockout has the absolute best documentation of any client side framework.

    • I had the same problem, first researched Angular and I found it very interesting, but I could not stop learning Backbone because everyone was talking about it and i thought, this cannot be difficult.
      I found tons tutorials, all differents on structure and techniques and the more I learned the more I felt lost and stressed.

  13. Raj,

    Thanks for putting together this blog post. I think it is a pretty objective comparison of both the frameworks. I am primarily a backend developer and recently started web front-end development. Last year we choose BB for our project. The learning curve was a bit steep for me. It took me a while get my head wrapped around it. But when I looked at AngularJS it just looked awesome. I was able to get up to speed pretty fast and we are planning to switch BB to AngularJS in our app.

  14. I think it should be mentioned that a strong plus with AngularJS is that due to it’s use of Dependency Injection your code is far more easily testable. Google AngularJS developer Miško Hevery’s automated testing (and testable code) is legendary and it shows.

    Another benefit gained from DI is your code is not littered with framework specific functions. I have found it very portable between our frontend and our NodeJS backend for this very reason.

  15. Great article. I am a Javascript developer for years now. I am getting my hand first into these frameworks. They solve two different purpose. BB would force you to better organize your code, force you to think RESTful way. You will be in total control of what you are doing by writing well informed code. Angular does lot of things for you which is great for someone looking for faster development. But better spend time to understand how Angular does the magic. We can write maintainable code base using both frameworks.

    With no hands-on coding experience in these frameworks, my assessment is “BB is a framework and Angular is a language.”

    • You are absolutely right. BB is a framework while Angular is a language. But, I think, it is a language built for a specific purpose.. i.e web development.

  16. Thanks for the write-up, I’m considering JavaScript MVC frameworks at the moment, so this is helpful.

    One note: It’s “farce”, not “farse”, unless you are writing Middle English, which is oh so 600 years ago.

      • Just to be anal:

        scenario’s
        Dev’s
        view’s
        model’s
        plugin’s
        collection’s
        backend’s
        verb’s
        binding’s
        irk’s
        engine’s
        test’s
        plugin’s
        dev’s
        set’s
        win’s
        framework’s
        designer’s
        id’s
        pay’s
        scenario’s
        scenario’s
        scenario’s
        diff’s

        I’m honestly trying to help you out here – apostrophes are rather distracting for developers, as correct syntax is our bread and butter :)

  17. Hi Raj,

    We are in the process of evaluating Angular for an mWeb Ecommerce site.
    This is for a fortune 100 retailer.
    It is a complex eCom site running on a mobile device which has very complex business logic that supports plethora of product types, shipping options,payment options and what not. This will also have a very big user base.
    The idea is a rewrite using Angular and access a thin server layer (J2EE) which in turn talks to the backend services .

    My question is how practical is it for an enterprise application of this size?
    This application is not an SPA, also there are data encryption , session management , error logging for customer support etc.

    The examples I have seen and opinions I have heard are usually based on a To Do app or may be a smaller application.

    Please let me know your thoughts.

  18. When I saw AngularJS tutorial and did some labs, I was pretty amazed by the power. It appears to me as new paradigm shift for web application development.

    The foundation of this framework is remarkable as it enhances existing language i.e. the tried and tested HTML.

    Being new to framework based web development , I will stick to Angular, its future looks promising.

  19. Hello Raj,

    Attempted reply to your comments down here. Apologies for the base comments, they were incited by the vitriol I was reading above… Late at night, after a long day working, attempting to do some research of my own (Your post was #1 in my Google search BTW, so good on you, with your shouting – apparently it worked to some degree or another ;).

    I’m not well versed enough in Angular to comment in depth, but I’ve used it on a couple of projects recently. I’ve also used Backbone (to a more in depth degree). While I agree with some of the reasons you stated in your article for using Angular over Backbone (on a project-to-project basis), to me, it’s not about framework X outperforming framework Y – it’s about the ways in which different set of tools can help solve various problems.

    You’ve stated numerous benefits re: Angular (that it’s fast, that many high-level problems are solved/chosen for you, and that it doesn’t rely on numerous plugins to handle tasks that are outside of Backbone’s basic scope). Totally agree, very awesome in that regard, and very useful – for me, personally, probably in a small majority of my projects.

    On the other hand, there are times when I need to do something out of the box. Or something that is smaller in scope than some enterprise level website with tiers of organized data structures, but still large enough to require MV* style organization, and most-likely creatively focused.

    I will choose Backbone everytime for a project of this nature.

    You claim that the notion of Backbone being a minimal framework is (apologies for paraphrasing) “the biggest farce in the history of mankind”, but you seem to go on to only point out a subjectively chosen set of reasons why you wouldn’t want to use a minimal framework. You don’t directly dispute it’s minimal nature at any point of that section of your article.

    But this element of Backbone is what makes it so useful in other ways – specifically in the Addy Osmani frame of reference (where a developer is exploring & developing new techniques & toolkits of their own), and in non-typical, creative/outside-the-box projects.

    At the end of the day, I believe that it’s equally important for the developer to understand the underlying principles as it is to be able to efficiently program them. So I really do think it’s a shame that an article, so clearly one-sided, should be hanging around at the top of a particular niche longtail search topic, masquerading as “objective”. You could have done much better than this.

    • Could you provide example of these creative / outside-of-the-box projects ( perhaps a short description of the project with features listed ? ) with reasons citing why for this particular project Backbone is more suitable than Angular?

      The reason I havent cited any scenario’s where I would pick Backbone over Angular ( Objective reasoning here, not just because of my personal likings ) is because quite frankly there arent any as far as I can see. Not small projects, not large.. not in between either. I think I did mention somewhere along in my post that in every scenario where you could consider using Backbone, you can use Angular and be better off because of that choice , due to the various reasons I have already provided.

      Backbone is minimalistic is an extension of Backbone is compact point.. This point tries to get back at comments like “Look this library is soo small and yet it does soo much”.. Does it ? Really? And what does it do ?

      • Sorry Raj, I’m not going to spend time delving into this further with you.

        There’s no dialectic with someone who has a such a set point of view. Eamonn’s comment below is spot on as well.

        But suffice to say, that you are not looking at this through anywhere near an objective lens. You should really stop using that term in conjunction with this article.

        Minimalism & bytesize are not correlated. But I guess you understand the concept of minimal even less than I gave you credit for.

        • Actually I’d prefer we quit trying to get objective. Developer experience is subjective. What we need is people like Raj who have done both and give their opinion. I never did much with BB, so I’m not qualified to compare it with Angular. But I did a ton with jQuery and jQuery UI, and then some with jQuery Mobile for 3 years. I am qualified to say that I’m a total Angular fan because after 6 months of angular I never want to go back. Certainly there are times when I’ll need my jQuery tool belt. That being said, does it really help people make the right decision by giving them a balanced view with long lists of PRO’s and CON’s, and ending with the usual wisdom of “It depends”?

  20. I have used both Angular and Backbone, and would generally pick Angular, though I think it really depends on what you are building.

    The title of your post is misleading. It should have been titled “why I think Angular is better than Backbone”. I find this article to be a hatchet job, and completely biased, bashing Backbone even though you have stated that it is not. You seem to have made no genuine attempt to see where Backbone might excel over AngularJs.

    • Do you know a scenario where it excels over Angular? Please feel free to add in the comments scenario’s where it actually does. Provide scenario’s where Backbone does actually excel over Angular?

      • Honestly – stop asking this question to every person who criticizes your article. The level of obtuseness required for you to continually miss the point is staggering.

        • Ummm Mike, you have started to sound like a 16 yr old who cant argue about the topic and have suddenly resorted to calling names…

          The question IS VALID.. If you can answer it or if eamonn or anyone can – and give plausible reasoning to say that due to this and this reason we cant use Angular in this scenario but we can use Backbone and its a better fit, I will accept it. I am not closed to seeing reasoning – if there is some. But until you show me this, I would be skeptical about it.

          Seriously, I was expecting a conversation with a mature individual not a kid going through puberty. Stay on topic and stop calling names.. grow up!

          • Yeah agree with Raj here, if you say the article is biased and there are examples where BB beats Angular, and he just asks you for an example and you get upset, you need to grow up and learn how to communicate.

            P.s. never used either framework; would actually appreciate one of the whiners adding something useful to the conversation.

            P.p.s. Saying “calling us whiners is a GREAT way to get us to help you!!11eleven” is equally dumb. If you do something wrong; apologise and fix it. If you don’t then explain why it wasn’t wrong. Don’t attack the person when it’s about you.

            Byeeee

        • Honestly, I’ve agreed with every comment Mike has made here. The fact that we can’t come up with a precise scenario in which Backbone is better than Angular isn’t a shortcoming of your critics. It isn’t really an answerable question, because the answer is always “It depends”. The fact that you are so convinced that a single tool is right for every job is indicative of your lack of experience. Get a few more years under your belt, padawan.

  21. Backbone.js you’re up and running, RESTfully creating new objects, fetching lists of objects, and updating existing objects in a matter of minutes. In fact, if you have backbone.js on your webpage, just paste the following in your browser’s command line:

    // Copy From here …
    var Cat = Backbone.Model.extend({
    urlRoot: “/cats”
    });
    var CatCollection = Backbone.Collection.extend({
    url: “/cats”,
    model: Cat
    });
    var Cats = new CatCollection;
    Cats.fetch();
    var cat1 = new Cat({ ‘id’: 1 });
    cat1.fetch();
    var cat2 = new Cat({ ‘id’ : 2 });
    cat2.set(“name”, “tiger”);
    cat2.save();
    // … to here (no CS degree required)

    Obviously you’ll get 3 network errors (unless you handle a “cats” resource on your server), but you will see (by inspecting the network requests) that if you actually had the routes, that Backbone.js and RESTful API are like peas and carrots.

    Is there a good AngularJS tutorial that can show me how to interact with a RESTful API for the full life cycle of an object (Create, Read, Update, Delete (and List amongst other instances of the same model))?

  22. “If the framework doesn’t write the code, YOU have to.”

    I am finding that AngularJS requires that I write all the “M” (model) and RESTful API interaction code that comes with Backbone.js for free.

    Why doesn’t the following automatically update the $scope.cats collection within my CatsCtrl? Is there a better way than $scope.cats.push(cat)?

    // from here …
    function CatsCtrl($scope, $resource) {
    $scope.Cats = $resource(“/cats/:id”, {
    ‘id’ : ‘@id’
    }, {
    update: {method:’PUT’}
    });

    $scope.Cats.query(function(cats) {
    $scope.cats = cats;
    $scope.Cats.save({ “name” : “tiger” }, function(cat) {
    console.log(cat);
    console.log($scope.cats);
    });
    });
    }
    // … to here

    Does AngularJS recommend using Backbone.js, or another library, for “M” (model) and RESTful API interaction code?

    Here’s an AngularJS app that seems to use other libraries for the “M” code http://ericterpstra.com/2012/10/example-crud-app-starring-angularjs-backbone-parse-stackmob-and-yeoman/

    It’s been less than a week of study, but I think that I’ll agree with Addy Osmani on using Backbone.js and Require.js + AMD ( +use.js ), and jQuery for large applications http://addyosmani.com/blog/short-musings-on-javascript-mv-tech-stacks/

  23. Hey there!

    Thanks for the article man, it was really informative.
    Eplained a lot of stuff per se.

    Guys, what do you think of the fact of using AngularJS in a JEE environmet, RESTful web services of course?
    I want to know what’s the take in using it especially when it comes to retrieving data from a MySQL database all in a JEE environment fo course.

    In fact I’m an intern in a company and I’m asked to develop an application that uses heavy database requests and resut inti drawing charts and graphics. So I have the choice between GWT and angularJS for this mission.

    So, which one of them do u think fits thebest.

    Cheers

    • If its all charts and graphs, you will have to probably write a few directives ( angular js custom components ) yourself.. Do you know any libraries like d3 or raphaeljs ?

      I dont really know the support for charts and graphs in GWT but I think they do have quite a few widgets which can be easily plugged into this. If its a complete java house and you know java extremely well and have no idea or a beginner in javascript then GWT might be better for you. If on the other hand you want to learn javascript, or have a decent understanding of js – then I would suggest angularjs with a combination of other charting and graphing libraries.

      Interacting with any RESTful web service is the same. To the front-end it doesnt make any difference whether the backend is written in JEE or nodejs.. Its all the same. That is why we have protocols.. HTTP is the protocol and once that is defined, it really doesnt matter what the front-end or the backend is.

      • Hello raj

        thanks for the response, that was fast.

        In fact i have been looking into AngularJS for the past two weeks, I liked it a lot and seemd very exciting to me especially the directive writing possibility: it’s like writing you own framework you know.
        On the other hand i’m afraid of the data retrieval from the database, conveying it to AngularJS to be displayed as charts, tables, etc. I also got the vibe that it would take me a lot of time to apprhend the new things that AngularJS presents. (i just have 3 months)
        I mean I can’t find any clear exampls abou it.

        As for my experience, well I have some knowledge in Java and some Basic JS stuff.

        I’m in my Computer Science engineering graduation project u know. So I haven’t got too much experience in any specific language. :p it’s good to learn new stuff though. But one should consider time contraints etc…

        As for GWT I think it can use Java charting APIs.

  24. People should check out Ember.js. It offers much better handling of the model (the *M* in MVC) and this is critical for more complex applications where you don’t want to custom write all your own model handling. Use “ember-rest.js” if you’re looking for RESTful library comparable to Backbone.js.

    Though there’s a lot of “automagic” in Ember.js, which I think makes it harder to learn. However once you figure out all the automagically created route controllers, model controllers and view controllers, and instantiate your own instead, then you will understand what you are looking at, and what else you can do. They should offer a non-automagic Ember.js.

    http://www.discourse.org has their source code on github. the link is somewhere on this page http://eviltrout.com/2013/02/10/why-discourse-uses-emberjs.html

  25. Once in a while we come across a post that breaks up a difficult-to-grasp topic into buckets in the programmer’s mind, (like a neatly fitting completed row as in tetris) , and this is one of them. Thanks Raj for the experienced insight into the comparison. I was going the BB way but for now think Angular, as in everything else Google has done, has the most simplistic approach so we can learn it quickly. I just hope they dont shelve it as is their trend of late.

  26. Angular is great. And AngularUI gives you some really cool effects for free. You get into a quick rhythm with Angular: create a template, bind a model, write a test, etc.

    But, I don’t use Angular for everything. Some apps were written before I discovered Angular. Some were written by someone else. Angular breaks the cardinal rule:

    Don’t make your view dependent on your business logic.

    Angular forces you to add Angular to your HTML. Your template is tightly coupled with Angular. Which is fine if you’re going to write it once and never use anything but Angular controllers to populate angular $scope models to build your HTML.

    But HTML should work without the framework. It should work with multiple frameworks. It should be able to be manipulated client side and server side. It shouldn’t be your only view.

    With Angular, your view only works with Angular. It just looks like HTML. But also, with Angular, your view can only be HTML. Your logic is tied to your HTML view.

    • It’s true that Angular couples your html to your controller. But is there really any way to escape this coupling? If you’re not dropping JS into your html, you’re dropping html into your JS, for example $(‘#hello’) introduces a coupling between JS and html. A lot of the time these couplings become deep, like $(‘#hello’).children(‘.foo’) which assumes a nesting structure on the HTML.

      Ultimately some level of communication between JS and view has to be hardcoded. You can have an opinion of what type of dependency you prefer, but you can’t escape it.

  27. Just wanted to point out, I’ve had great success implementing Backbone with jquery plugins. Especially if the plugin removes it’s own events. Further more I’ve had success writing Backbone sites for small single page apps, and a large app that targets 5 major cities in the US. I have found a use case for data-attributes in my markup for smaller backbone projects with patternless templates, and for larger projects with pattern consistent templates and data; rendering each model into a view.

    What turned me off about Angular is applying logic to my templates and markup, it’s size, it’s immaturity, and the community, (I’m in NYC.)

    I understand Angular removes the need for manual DOM manipulation, which is a huge maintainability win. I also understand that Chrome is adding data binding much like Angular to the native browser. Anyone who has affiliation with Google is biased towards Angular for both these reasons.

    My markup will remain semantic, none of these data-ng attributes will exist. Just clean semantic HTML. My templating language is Mustache and is shared on the client in Mustache.js, and server with PHP, mustache.php; and Pystache, in Python.

    Further more comparing the client list from the two frameworks, it’s obvious which comes out on top. It’s dependence in jQuery is minimal, we are working on two builds one with 1.9.1 and one with 2.0. jQuery will remain the heart of every frontend application, Backbone will continue to structure those applications.

    When evaluating some kind of MVT for my current company, we too looked at all the libraries you have listed. We chose BackboneJS.

    • I never said you cant succeed writing code in Backbone. I said, the same code if written with Angular will be quicker and you would be writing far less code.

      I am not sure if you read my blog, but I did a thorough investigation on size comparing what Backbone requires and what Angular provides. Its immaturity ? If you still think Angular is immature, I think you are heavily mistaken. Community – the problem is there is no proper measure for this. Its all going to be subjective indicators. Just a comparison, have a look at the google group communities for both Angular and Backbone ( especially look at the members and statistics section ) https://groups.google.com/forum/?fromgroups#!aboutgroup/angular
      https://groups.google.com/forum/?fromgroups#!aboutgroup/backbonejs

      Chrome isnt adding data-binding as far as I am aware of. There is nothing Google specific in Angular and Angular doesnt work better in Chrome compared to say IE or FF.

      If anything angular makes your HTML more semantic ( https://en.wikipedia.org/wiki/Semantic_HTML ). Semantic is to provide meaning. If someone reads your html he should understand what is happening there. But the presentation ( how it looks ) should not be part of it. So semantically, Angular is better than Backbone because someone reading your HTML wont know what is happening there.

      Angular does not contain any more logic than your typical html attribute. With angular you are defining new attributes. I have already mentioned this in the article, but if your markup does not contain any references to the code then your code contains references to the markup. Its one way or the other.

      • I think what Michael means w/ Chrome and “data binding” is their web components (basically custom tags that encapsulate HTML snippets and javascript) support.

        I think the HTML markup and directives is what people have the hardest times grasping w/ AngularJS. It’s just so far from the concept of jQuery and manipulating the DOM that people are used to that it’s foreign but BackBone/Marionette, etc. let you merge in jQuery plugins easily. In AngularJS, it’s harder because you have to change the jQuery init code to Angular directive setup code.

        Still…less code in AngularJS and easy testability are big pluses for me…

      • I’m a web designer (mainly PSD to HTML/CSS) trying to get hang of Angular and such frameworks. Currently I’m working on a project which uses Backbone and the html markup is very clean, and I like it that way. Reason being, the over-all design keeps changing at least twice a year depending on “Seasons” (FW-> fall winter) and (SS -> Spring Summer) and I keep changing the CSS (mostly) and (modify the ) HTML markup to reflect the design change.

        At first thought, I realize this, if it were to be Angular, won’t the JS dev guys have lot at hand to keep modifying the markup I provide them rather with Backbone where they just specify “class” or “id” ?

        And semantics means, like you say, is to provide meaning and should be readable, for developers, (can be easily achieved with IDs and Classes which “controller” uses to do its job ??) and accessible to screen readers.

        Isn’t added custom attributes have impact on html size ? (relatively to just IDs and Classes)
        I have some more questions about various other points such as “Backbone IS opinionated”, and does it mean Angular doesn’t ?
        (sending from mobile, excuse the typos ;) )

  28. Very good & comprehensive comparison.
    Now I think the topic is closed, simply looking at the todoMVC project: size of the Backbone+Marionnette version is far bigger than Angular.

    So I think the real question now is Angular vs KO or Ember.
    I’m still not convinced by some of the concepts of Angular, & KO is underevaluated IMHO. Maybe because it is too simple to read?
    & actually it is faster http://jsperf.com/angular-vs-knockout-vs-ember/100

  29. I am a language lawyer, I have quite no real thinking constraints.
    Give a name of a quite common language and there is big chance I am proficient with it.
    I even wrote some parsers to toy with home made languages and have the feel of “language design”.

    I am very experienced with many idioms, imperative(Assembly), procedural(Baisc), data driven(SQL), data flow driven(Labview), functional (Lis), Stack based (RPN, NUSP, …) , declarative, … And their respective “* patterns”.

    So am I with JavaScript and AngularJS.

    When you know what has to be server-side and client side, what you can actually afford to do on client side and the cost of each solution then you can do really magical stuff in AngularJS.

    The most costly operation in a stack like “LAMP” is :
    - DOM manipulation
    - Networking
    - Client side processing
    - Server side processing

    If you scroll a list of 1 thousand items which are constantly updated in AngularJS, you will kill the application. Introducing pagination will simply make it work “instantly”.

    That’s one of the major counter point for AngularJS: it is too accessible.
    corollary 1: people may be shadowed the fact that there is DOM manipulation behind.
    corollary 2: there is more than one way to do the same thing.
    corollary 2.a: Some of these ways are betters than others.

    Another major disadvantage of AngularJS: it is too flexible.
    corollary 1: people aren’t enough guided.
    corollary 1.a: people can do wrong and flame AngularJS.

    I do i8n in my AngularJS, charting, data drill down, dashboards.
    It does cut my development time by weeks.

    As soon one realize that it works perfectly with REST and create services, directives, filters and modules then you mostly have to “copy paste” scripts includes to create your projects.

    Among developers, the fears of solutions claiming to “do it all at once” is clearly understandable, but AngularJS doesn’t say it. It says that it does the boilerplate for you, the plumbing.

    All components are highly reusable per se.

    KR,
    Christian

  30. I want to read this article… but… I can’t stomach the BS… Do you really think you need 37 exclamation points? Is “Backbone is minimalistic” really “the biggest farce in the history of mankind”? Do you think you are winning over a lot of Backbone developers with “Your wrong. Again!” Your “style” is getting in the way of your content!!! And that’s the dumbest stupidest wrongest thing ever in the world to infinity squared.

    • If you are here for the content, you are welcome. If you are here for the tone, I believe there are 1000′s of other articles out there.

  31. Backbone was my first love when I started using MVC JS frameworks. I still think it is a fantastic framework and it has a really small footprint, but lately I am finding the features of Angular too tempting to resist. Ember looks good too and I have played with it a little, but haven’t had enough time to really explore it.

    One of the downsides of Angular is that is is relatively new so there is not yet a lot of support in places like stackoverflow – certainly nothing like what exists for backbone, but in time I think that will change.

  32. Another twist for your analogy:

    Your boat only drives straight. As long as the sea doesn’t throw too many big waves your way…you’ll make it there well enough.

    • Can you elaborate on that?

      I dont think you need a templating engine with Angular. If you have strong opinions as to why you would need them ( even for custom components! ) please elaborate.

      Please note, we are not saying that we dont need a template. We are saying that we do not need an external ( non angular ) Templating engine. In fact, I have not heard of anyone using a templating engine with Angular.

  33. “If the framework doesn’t write the code, YOU have to”

    That was one of the most beautiful sentences I’ve heard in my life. Thanks for such a great comparison. Thanks for the time you spent on learning these frameworks and comparing them that detailed.

  34. Raj, thank you for the post above. Judging from the discussion above (that have been going on from some time now) it appears to me that you don’t quite listen to others or take fully consider differing perspectives. Given that, and the fact that you seem to be advocating one Framework over another rather than giving an objective analysis, I am afraid that I cannot use this post in considering a Framework to select for an up and coming project. I post this because only because I think that there is an opportunity for you to grow from this and better serve the software community whom you obviously care about or you would not have blogged such a well written (if not flawed) treatment.

    • Hi Eric,

      Thank you for the comment. It would be wonderful if you could let me know where I have flawed and where you think it is not objective enough. I understand that the tone of the blog seems biased but it is so, for a very specific reason. I hope you could get atleast something out of it and would appreciate if you could give me very specific points where I could correct the mistakes and make things more objective.

  35. Hey Raj,

    Fascinating post, and I really enjoyed it. Sure, maybe it was partially subjective, but I felt you laid out your case for Angular succinctly and thoroughly. And personally I’m pretty sold. Keep up the good work.

  36. Maybe you should consider that monolithic frameworks like angular will never be adapted to specific cases like backbone does, for a very simple reason, backbone at least tries not to be opiniated.

    You’ll be very quick while coding “standard” cases, but you’ll fight with mills if you try to go out the road angular has drawn for you.

    Some prefer this way of coding, I don’t.

    • I am not sure if you have tried angular. I have experience with both and as far as I can tell there is no single case or scenario where you would struggle with Angular ( and fight against it ) while the same implementation would be smooth sailing in Backbone.

      The whole point of the post was to show you that Backbone IS Opinionated and you cant get away with its opinion as the popular belief is. Everyone thinks that because it is lightweight and doesnt do much work for you it is not opinionated. This is actually one of the biggest mistakes people do. As far as I can tell Angular is not Opinionated in most cases. It has opinions on code structure ( which is good ) but I dont see it coming in the way of anything I do. I would think that unless you are writing a Canvas application ( a game perhaps ? ) Angular would be a good fit.

  37. I’ve been on the fence with trying Angular on a project for a while now. The main reason why I have not yet is I’ve found Backbone Flexible and Unopinionated enough to create a focused architecture using Reactive Programming and commonjs modules (via browserify). I’m also able to easily execute the code on the server, which is great for SEO.

    The DOM binding logic tends to be pretty trivial. What tends to be more troublesome is integrating with services, transforming data into consumable pieces (especially if you are not in control of the service), and full coverage testing.

    I created https://github.com/btakita/backbone-signal for reactive programming and https://github.com/btakita/jasmine-flow to test the many edge cases in a scalable way.

    I appreciate how frameworks provide a backdrop and common language for a team of developers to rally around. The unfortunate thing is the idioms of a framework take precedence over the idioms of your business domain.

    I prefer to make the application domain front determine the high level directory structure (no need for the parallel models, views, templates, images, and css directories).

    I also like keeping the javascript code very light. One affordance that CommonJS modules give is you can rewrite a stripped down feature set a plugin gives at a fraction of the code. I rarely use all of the functionality within a plugin. CommonJS makes it very easy to use only what is needed, giving you the functionality you desire for a fraction of the code.

    I think the boat analogy between BackboneJS and Angular is a bit different. With Backbone, you have a the parts to make a custom boat. With Angular, you have a top line stock store bought boat with a bunch of bells and whistles.

    For most people, the store bought boat will be easier to get up and running but building an extension to fit your exact conditions.

    If you are making a race boat, the custom boat will give you more potential to make something faster, lighter without the unnecessary bells and whistles.

    The quality of the boat is more variable on the quality of the designer/builder than the store bought boat.

    Regarding technicians, both boats will require the technician to learn the custom configurations.

    The store bought boat will have certified technicians who are trained with constructs of the stock boat.

    The custom boat will require other technicians to learn the constructs of the custom boat.

    If the store bought boat has aspects that fight the requirements, such as replacing the general purpose hull with a stripped down, lightweight carbon fiber hull, then it would probably be better to make a custom boat.

    Given all that, I think one can do even better than Backbone.js. Stapes.js, weighing in at a svelte 2kb min + gzip, looks promising…

  38. Pingback: Best JavaScript MVC Frameworks 2013-2014 - JonathanMH

  39. Pingback: AngularJS: Clearing a few confusion points. | Next Big Thing

  40. There are some fundamental concepts to take on board when choosing to adopt either AngularJS or BackboneJS that fall into the scope of this document but are overlooked.

    i. Angular is similar to Adobe Flex in so much that your markup will require code directives. This creates an overhead;

    debugging your presentation/templates.
    reducing re-usability as templates are joined at the hip with the logic

    If you’re a fan of keeping your presentation and logic tiers seperated, Angular is not for you. For me, this is a complete show stopper.

    ii. The “cost” identified in the main article generally surrounds file sizes and decisions, like electing to compile a feature into a server kernel.

    iii. There are fantastic options for databinding backbone these days; “stickit” from the New York times; “ractiv” from the Guardian. This is an older article.

    iv. Overriding the sync method to enable XML instead of REST is not hard and is consumed in good practice. REST is supplied as a default, and an example.

    • You are absolutely right about angular being similar to Flex. You are also absolutely right about requiring directives in the markup when using angular. Angular’s philosophy is to extend html to provide new elements, attributes etc. There is no question of debugging your presentation / templates – and you are absolutely wrong in this section. Do you debug your html? Honestly, Angular is soo popular these days because of its re-usability. The point being, in most cases you dont really have to write these additional directives and could happily write more than 90% of your project with what is already provided to you with Angular. This is declarative style ( which is what html is meant to be actually ) and I will bet my career on the fact that this is where the web is headed ( look out for shadow DOM, web components etc! ). Feel free to ignore it until it becomes mainstream at your own loss. The reason I am saying that this will become mainstream is because – every other UI language is this way.

      Angular is actually the one that separates presentation and logic completely. In Backbone, you might be able to take out the javascript from the html, but can you take out the html from the javascript? Every piece of jquery-esque code that you write in littered with DOM querying and manipulating the DOM in one way or another to change the state of the UI.

      About data-binding : Yes, ractive from Guardian is one of the better data-binding libraries that I have seen lately – and I do know that it works well with Backbone. In this regard, this blog is slightly older and at the time of writing there were not many options for backbone.

      I did not say that overriding the sync method is hard. Just was pointing that doing that felt like a hack because there was no single consistent place to do that.

  41. I use dojo for front-end development, and staring exploring backbone and Angular. To me, your opinions are practical. Also, I like your analog of motor boat and lifejacket. Great work!

  42. I agree on many points, but there’s a problem with that “no DOM manipulation from controller”, small amount of extensions and related inability to directly operate over other libraries / DOM-manipulating things. My impression is that Angular.JS doesn’t play good with others.
    Here’s my story.
    I have an old project with lots of jQuery plugins, 3rd party libraries (network and data processing related) and lots of functionality (this is a shipping service, both admin panel and front end with lots of reports, statistics and utilities that in the end looks like moderate CRM).
    At first I’ve tried to go with Angular.JS. Now it is fashionable, last word from Google in web-dev, actively developed, strong and growing community and etc… I’ve read some guides, went though a bunch of videos and tutorials, consulted with community (#angularjs @ irc.freenode.net) .
    After all this and a month of development I ended up with a very crappy implementation, dozens of directives for wrapping jQuery plugins, services for other 3rd party libraries and refactored common routines. I’ve just told myself to stop. Thought to completely rewrite whole damn thing (I learned a lot while implementing it), but I’ve had a couple of free weeks so I could experiment a bit. First thing that I’ve stumbled upon was Backbone.JS (still quiet popular library), raw Backbone.JS was useless (loud, but the point is that too much stuff has to be done manually, indeed, here I agree with you), but add here Marionette.JS and things look very differently. I rewrote whole application for less than 2 weeks. There are still some controversial moments and not everything is as good as I would like it to be: there’s code duplication, lots of events (I suspect I should throw away at least a half of them), changes done to core components (especially routing and Backbone.sync, because app is not RESTful), but I find this to be much, much better than it was with Angular.JS. Maybe in my case with Angular.JS something went wrong and I just don’t see it. I don’t know.

    Also I find some very controversial argumentation in your article. First of all Backbone.JS itself is not a framework. It is even stated at its homepage. Trying to put Backbone.JS against Angular.JS is the same as putting jQuery against Underscore.JS. Backbone is indeed a backbone, a bare minimum: models, collections, very simple routing and views. Add here Marionette.JS and you get structuring, much better views governance, layouts, modules, additional components that you can’t live without in moderate/large scale project. Comparing Marionette.JS with Angular.JS looks more appropriate to me. Also the fact that Backbone.JS is opinionated (RESTful, no embedded objects) is pretty controversial here, too. When I’ve been trying to rewrite with Angular.JS I’ve had 2 options: either use $http or $resource. $http is bare AJAX query basically so trying to adopt it = rewriting $resource. I’ve end up with configured $resource. In case with Backbone I’ve messed with Backbone.sync and base model class. That looks pretty good. I can’t say it is shorter than Angular.JS or better in any kind of way, but I’m statisfied with the result. And about nested objects it is indeed so, Backbone.JS out of the box doesn’t support that, but I went another way: https://github.com/samduvall/backbone-relationships – I’ve moved them to separate model. I can’t call this super pretty solution, but in the end it works and it works good. There was a number of issues with it, but because I don’t have many invocations of it I can live with that. Also I’ve looked through Backbone.Model and thought to write my own implementation with support of nested objects, but I discarded the idea because of time limit and I couldn’t foresee all possible issues that could be caused in plugins and Marionette.JS. The only thing that I indeed didn’t like very much is those get() and set() everywhere, hands down in this case Angular.JS is winner.

    My conclusion after all is that today *for me* after comparing Marionette.JS with Angular.JS I choose Marionette.JS. Maybe in future when Angular.JS will become more mature and will play better with other libraries and won’t require separate directive/service for everything and anything I’ll make a switch. Until then I don’t see any reasons to choose it.

    • This is one of the most informative comments (disclosure: it mirrors my experience as well) because it reflects a real world scenario: you already have a field-tested JS code base, it’s experiencing growing pains, relies heavily on 3rd party plugins that have nothing to do with AngularJS and may be too mission-critical to rewrite or just very high quality. I might also add, in my case there were issues of scale when the DOM grew large and data changed many times before needing rendering.

      AngularJS was a nightmare. Every plugin that wasn’t completely incompatible required hideous hacks, often with $scope.watch overrides. Undesired rendering calls on intermediary values slowed down performance and looked awful. DOM control was unpredictably to retake when needed to pull off aforesaid hacks. Someone mentioned insightfully earlier that Backbone respects The UNIX Way. It’s true. The time you invest up front in researching the right superstructure (be it Marionette, Chaplin, a custom plugin mix, or your own) pays huge dividends in agile development and critical bug fixes when you just need the framework to BACK THE @#$% OFF and let you write Javascript and DOM either to create or optimize something the framework didn’t anticipate. There is little room to do this with Angular. You have to develop your app in it from the fundament, with components that neither play nicely with others that don’t respect its conventions, nor work when its own pieces are used outside of Angular.

      It’s MV* feels like one giant step backwards to 90′s web development when there in fact quite little separation of concerns, view code riddled with operational logic, everything suckled on the milk of the core library. Even Misko Hevery in a Google Groups post when asked why so much data-binding was done directly into the HTML (which due to the “living standard” by the WHATWG, it absolutely frightens me how cavalier Hevery is about intruding into it) said “well, that data has to live somewhere.” In even the simplest Backbone app you can see that this was done far more safely at the JS side with the underscore templating engine (which if you don’t like you can drop in Mustache or whatever) under a developer-controlled render call. It amazes me how unimaginative the Angular afficionados are about the neat, manually-optional expendability of other templating engines are given the code gymnastics they write to do almost everything else in Angular.

      And I hate to appeal to authority, BUT, assuming successful companies have brainy tech leads, just who is using AngularJS outside of Google? Where do you recognize more companies who have and continued to get stuff done?

      Here?
      http://builtwith.angularjs.org/

      or here?
      http://backbonejs.org/#examples

  43. Pingback: Introduction to JavaScript MVC Frameworks – Angular, Ember, Backbone etc., : Mukthar A Shiek

  44. Pingback: Looking Ahead: Javascript in 2014 | blog.davebouwman.com

  45. Pingback: Looking Ahead: Javascript in 2014 | Esri DC Blog

  46. First of all both “frameworks” (as it is claimed that Angular is not a framework but a language) are awesome. If you are looking first time at both you will find Angular outstanding, and it is, all link together by “magic” and the learning curve (at the begining – no fancy stuff) is very smooth but it becomes abrupt once your app requirements evolve. Backbone is like a toolbox (with lot of plugins) that will help you build very nice and scalable apps. The learning curve is abrupt (at the begining) but it becomes smooth down the road. So it all depends to the programmer to decide if the app will get complicated or not -> planning. NOW the BOTH share ONE big PROBLEM as they both addresses to WEB APPS. There is a saying that a web app exists if people know about it. How people find about your app -> SEARCH ENGINE. Both are NOT FRIENDLY with SEO as they build SPA’s. Me, as a programmer find 3 solutions:
    1. use third party services as prerender.io to feed crawlers with good “food”.
    2. install on your server such a service using phantom.js (it’s a overhead but there are tutorials if you have rights on the server)
    3. use same, let call them “template files” that can be used to render on server as well on client. (have a look as mustache.php and mustache.js and it seams twing goes js already too).
    As we all, (i presume) can agree is that the last point make much sense that others. (there are php frameworks that ease this task such as ZF2, lavarel, symphony… basicaly any server mvc framework). Now if the seo wasn’t on my concern list I will go for sure with Angular(may I will go for an intranet portal), but since Angular doesn’t support template engine (or at least one that can be rendered server side) I’ve decided over Backbone. It’s true Backbone does not have the “magic” of Angular and sometimes you find yourself in a situation to write lot of boilerplate code or decide which solution is better from stackoverflow’s “pool” of answers but, hopefully in the final people will hear about your application from organic seo. As some wise men tweets: “there are no golden hammers, it all resumes to planing and decisions”. Hope this is a good case that will make you think about it. I hope my post doen’t hurt anyone feelings, but a good lecture. Have a nice programming.

  47. Pingback: My Angular JS Story so far | Hot Proton

  48. Your article is great. Backbone is opinionated. Backbone is not minimalist. Yes, they are a share of mindspace and is a Apple/Android situation.

    The lifejacket / motorboat analogy is amusing but be aware that a binary (two-choice) analogy offers an imperfect match to the case, and usually the speaker lends a bias toward the side that they wish you to choose. In your case, you assume there is gas in said boat in the middle of the ocean.

    So, if you wish to get to shore and you have a motorboat with no oars, no fricking gas, the computer science muscle power to start the engine, a 50% chance of developing a hole in the hull (a hungry tiger as a mate) or a simple lifejacket with no holes then you might get a split vote.

    The Apple and Android analogy is fair it theres no obvious bias, other than placing Apple first in the list.

  49. I tend not to leave a leave a response, however after looking at a lot of remarks here
    Backbonejs vs Angularjs : Demystifying the myths | Next Big Thing.
    I actually do have 2 questions for you if you don’t mind.
    Could it be simply me or do a few of the remarks come across as
    if they are coming from brain dead individuals? :-P And, if you are writing on other online social sites, I’d like to follow everything new you have to post.
    Could you make a list of every one of your public pages
    like your linkedin profile, Facebook page or twitter feed?

    my web site … advanced auto

  50. I honestly thought this was a balanced article but seriously as I was reading I kept feeling uncomfortable. You seem to be rather quick to take the term “opinionated” literally yet pretty loose when it comes to the term “minimalist”. You could not have sounded any more biased than you did. When people say that backbone is not opinionated they obviously do not mean that there is ZERO opinion regarding the way the framework was built. What they mean is that compared to angular, backbone is far more flexible and far less opinionated. Every piece of software ever made IS opinionated, even binary code was an opinion for god’s sakes. I really have no idea where exactly you were heading with that argument.

    Before I started to use angular and backbone i was building my own routing, controllers, requests and templating. Later on, I looked at angular and I felt like it was designed for people who had very little time to put a webapp together. Some developers however like to have a certain amount of control and flexibility as their building up their code. We go insane with the slightest performance issue and the slightest little bug, we just want it to be perfect. Sometimes a workaround for a couple of backbone’s limitations turns out to be better than having to commit to a baby sitter. I personally prefer backbone because of structure not because I want it to do things for me. For the most part I’m confident enough to know how to make my javascript code concise, flexible and accessible to other developers. I do not need angular to lead me on this. Some people really don’t mind having to write the code that the framework didn’t. In some instances I really do not mind rebuilding the wheel because every time I do so the damn wheel always turns out better than the previous one and that, to me, is satisfying.

  51. Hey Raj !! Though I have been working on web technologies from the past 8 yrs, I am very new to Javascript Frameworks. I was looking forward to create a eCommerce website with typical payment gateways, etc & I was looking up the internet to figure out which among Knockout & Backbone would suit my needs. However, I am quite impressed with AngularJS after reading your article. I will be using ASP.NET SPA & WebAPI. Do you think AngularJS would go well with this setup? Can you give me links to good articles on AngularJS?

  52. Loved reading this…

    Have you tried with famo.us js library? There is also integrated FW famous+angular.
    You have any thought to share on these. Any pros&cons? etc etc etc…

  53. You forgot a significant shortcoming of Angular: it’s of Google origin, which IMO represents a huge risk – chances are high it will go the same way GWT did.

    Given that, the learning curve with Angular is quite steep; if Angular does go the same way as GWT did, the learning effort will definitely not have paid off

    IMO both Angular and Backbone are a no-go for large and complicated single page apps. Neither provides a library of reusable UI widgets, and that’s where you spend most of your time – if you don’t have them. There are other frameworks, integrating support for MV* architectures with a rich UI toolkit, and those are IMO the way to go for complex single page apps.

  54. Last year I wrote an extension for Chrome/Opera where a special extension-page was connected to bg process. This allowed for the persistence layer to be in bg process and to have several of these “special pages” to be connected to it at once and send events between each other. This was super easy to do with Backbone but nearly impossible with angular.

    Also doing some operations in batches and then doing some stuff after (or before) is much more easier to do in Backbone than in angular resulting in actually much faster Backbone app (in some scenarios) than what angular could do.

    Angular seems to be missing any actual collections/models as well an so you actually have to write more code in angular than in backbone.

    Angular also seems to try bringing the “java” way of thinking into front-end web applications which is something I really hate, because I don’t think it is necessary or that it brings actually anything good. To understand angular you don’t need to be smarter (as author implies) but just to think in a different way that is not usual for front-end web apps. In the end I think people who write in backbone has to be actually smarter because they need to write more things themselves :)

    • I’m glad you brought that up… Who the heck said it was okay to bring back DIV soup & classitis? All that ground we gained with HTML5 and then Bootstrap happened… Filthy, filthy, filthy! *hoses off all the markups*

  55. Pingback: What are You Going to Learn This Month in Front-end Development?

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>