Knockout vs Backbone vs Angular

March 16, 2013 – 4:48 am Tags: , , ,

There’s a lot of talk of various client-side kind-of-mvc libraries. Three of the popular ones I’ve used are Knockout, Backbone and Angular.

While there are other comparisons of the three, I feel many of them don’t really touch on some of the aspects that I’ve come to learn from my experiences with the three.

First off, some observations of the individual libraries

Knockout

This was the first of the bunch I used. It offers a way to bind data into HTML by using special attributes and such.

Very easy to get started with, Knockout is the easiest to pick up of the three and gets you to doing things quickly.

It’s very good if you want to do things the library supports out of the box.

Where it fails in my experience is when you start getting more complicated behaviors or models. It becomes harder and harder to link behaviors with the data binding system when your models become more complex.

Backbone

Backbone is rather different from the other two. It doesn’t really give you a data binding facility as such, but rather a bunch of objects you can build your own MVC-ish solution with.

It’s quite nice when you want to build some more complex interactions or more complex models. It doesn’t really limit you because it doesn’t really give you anything high level either.

The downside of Backbone is boilerplate. You end up writing lots of code that’s mostly for wiring things together – things you get by default from Knockout and Angular with a few markup attributes. It also requires more understanding of how Backbone’s whole set of objects work together before you can do a lot.

Angular

In a similar sense as Knockout, Angular offers you data binding into DOM, but also a bunch of other things such as controllers and a ready to use set of “services” for building single page apps and other things.

Angular offers a quite easy entry into using it, but some of it can feel confusing. It uses more advanced features such as dependency injection quite a lot.

The main downside to Angular for me was that it was much harder to understand at first. Sure, the basics are easy to grasp, but once you need to do something it doesn’t do out of the box for you, it requires a much deeper understanding than the other two.

Comparing the libraries to each other

Knockout vs Angular

I think in most aspects, Knockout is easier to start with. Angular’s data binding feels more powerful than Knockout’s, but some of the ways it behaves can be hard to understand at first.

Angular relies much more on “magic” – things that seem to just work somehow – than Knockout. For example, Angular uses dependency injection to bring dependencies into components. This can be made to work purely by naming your function arguments with specific names, which can seem pretty weird at first – where does all that stuff come from?

However, Angular does not suffer from the problem Knockout has with more complex models: I think this is where Knockout’s limitations in the way it does data-binding starts to show, as you will need to craft your data into more Knockout-specific styles for it to work correctly with it. Angular on the other hand can handle a much wider variety.

Angular also has the added benefit of not requiring you to use “observables” in your model. In order for Knockout to be able to data bind things into the DOM, things must be wrapped into observables. Angular on the other hand uses more magic to solve this. Angular’s approach isn’t really that magical, but it’s rather opaque and you don’t see what’s happening under the hood as readily as with observables.

Knockout and Angular vs Backbone

I grouped this into one section since the comparisons for both Angular vs Backbone and Knockout vs Backbone are quite similar.

Backbone is the least “magical” of the bunch. This is simultaneously a good thing and a bad thing: It’s good because Backbone code is easier to understand in a way since everything you do usually needs to be explicitly coded, but the bad side is that it causes Backbone applications to require more boilerplate coding that isn’t necessary with Knockout or Angular.

Backbone is also quite easy to grasp. Everything is pretty much as it appears, quite simple JavaScript “classes” that have certain functions in them and certain ways they can be used. In Knockout you really don’t use that much objects from the library beyond observables and the data-binding features in the DOM, but when using data-binding you don’t really see what goes on in the background. Same applies to Angular, but to an even higher degree because Angular uses additional things like dependency injection which again is something that is done for you by the library’s own mechanisms that work hidden from you.

Backbone also has the least amount of surprises. Again because you need to wire things manually via your favorite DOM library and Backbone’s easy to use event system, you pretty much know what’s going on… templates are being created, values are assigned, etc.

Some surprises you can encounter with the other two are performance issues or obscure bugs/features with the data-binding not working the way you expected it to. In particular with Angular, it doesn’t always behave exactly like you’d think (could be because I still lack a full understanding of it – just goes to show…). An issue I had with both Knockout and Angular is also surprises in performance as mentioned: Certain situations can lead the data-binding code being extremely slow and requiring you to instead just generated the DOM by hand with the DOM APIs or other approaches.

So, which one comes out on top?

None of the three is clearly superior in every aspect.

Knockout has very low barrier of entry and if you need to put something quickly together, I think it comes out on top easily. However, if you need to build anything more complicated, it might be better to look at Angular.

Backbone is not just a data-binding facility; it has the groundwork to build all kinds of things. It does require more boilerplate, but it comes on top when you need to build more specialized solutions such as integrating with WebGL or 3rd party libraries.

Angular is very powerful. It seems very suitable for building more advanced apps, but certain aspects of it can be harder to understand. If you can put the time to learning it or have someone on hand to help, it can be a very good choice as the code it produces can be very readable and it has full support for automatic testing out of the box.

If I had to pick one of the bunch that wins, it would be Angular. It is however not a clear winner: It merely inches above the rest due to its power and convenience combined into one. It can require a lot of learning though to be able to use it to its full potential.

Want to learn more about JS frameworks and the best practices? Sign up for my newsletter!

Join now and learn the tricks to increase your productivity with the best frameworks

  • How to decide which framework is good for a project?
  • Page performance with big libraries
  • How to organize your code so it doesn't become an unmaintainable mess
  • And more

We will never sell your information or spam you, ever.

Share this:
  1. 11 Responses to “Knockout vs Backbone vs Angular”

  2. I have only used Knockout, but I have to say that I haven’t found a situation where I haven’t been able to do something with it. It has custom bindings which do allow you to do pretty much anything you want. What sort of things have you found it hard to do?

    By Paul Manzotti on Mar 18, 2013

  3. My problems with it have mostly been related to needing to jump through hoops to get models to bind.

    For example, if I have a rich model on the client with various JS objects that have much custom behavior, I either have to couple those objects into knockout (using observables), or I need to create functions to convert the models into objects knockout can use.

    Neither of these solutions is really optimal in my opinion. Comparing to angular, you can directly bind into the objects without having to do any sort of conversion or such so I feel it’s much more convenient when you have a more complicated application.

    By Jani Hartikainen on Mar 19, 2013

  4. Pretty good comparison. I agree with the boilerplate of Backbone. And so do many others- That’s why Marionette was born. To help reduce a bunch of the wiring logic. Backbone+Marionette+ModelBinder appears to be a pretty solid trifecta at this point, from my standpoint. I prefer the separation of concerns when it comes to the behavior and structure of a website. Binding data with attributes still just feels wrong to me.

    By Chris Rueber on Mar 19, 2013

  5. The knockout mapping plugin (http://knockoutjs.com/documentation/plugins-mapping.html) can really help you out with creating objects. Have a look at a recent answer I gave (and was helped with) on StackOverflow for a good example of this: http://stackoverflow.com/questions/15480316/knockout-dynamic-binding-issue

    As for decoupling your view models, I like to use a pubsub framework to allow models to talk to each other but still staying decoupled: http://stackoverflow.com/questions/14555381/variable-dependency-with-knockoutjs/14559492#14559492

    For simpler pubsub, there is this knockout extension https://github.com/rniemeyer/knockout-postbox

    Does all that help at all?

    By Paul Manzotti on Mar 20, 2013

  6. @Chris personally I prefer attributes, mostly if you consider the fact that when you change markup, you may often need to change your data-binding slightly as well. With bindings in the markup, I think it’s a bit more clear what you need to do in order to keep things working.

    @Paul interesting stuff, I’m not sure if it feels as elegant as Angular’s solution, but it does address some of my concerns :)

    By Jani Hartikainen on Mar 20, 2013

  7. I’m sticking with BackboneJS, it was the first that I learned and it’s the one I understand. Angular is interesting but the `magic` throws me, I like to know exactly what my code is doing and backbone gives me that.

    By Tony on Mar 21, 2013

  8. I’ve been working with AngularJS for a couple weeks now, and am actually redoing an app to use it. Overall, I think it’s a very powerful JS framework. But, I do have one complaint/critique. I’ve read everything I can about the AngularJS service vs factory vs provider, and I find the distinction to between the three to be rather nebulous, which might be why you can’t find a good explanation of the three and when/why each should be used.

    In fact, if you look inside angular.js, you find that a service ends up getting wrapped inside a factory, and a factory ends up getting wrapped inside the $get function of a provider.

    I think the confusion partially derives from the fact that, in Java world, you’re used to the idea that a factory class actually has a distinguishable purpose from a service class, and it’s a distinction that fails to actually present itself in JS-land.

    It makes me believe that the author of AngularJS is being too smart by half by trying to introduce patterns to JS, which can’t really be justified, in order to make the framework seem more complete than it really is.

    I do see a purpose of being able to inject a provider into config, and that’s a clear distinction from service and factory. But, the rest seems to be a difference without a distinction.

    I’m happy to be shown wrong. In fact, maybe this will elicit a better explanation than the lousy, inadequate ones currently out there, along with good examples (keyword GOOD) that show where only a factory would suffice in a given situation and service or provider just wouldn’t cut it.

    By Ron on Mar 31, 2013

  9. Thanks for the write up up, one thing that I spotted here which I don’t think is true is having to define all JavaScript properties as observable. I was able to bind simple properties too.

    By Paul Stoker on Apr 20, 2013

  10. @Ron,

    The guy who originally started Angular is a TDD-guru from Google if I remember correctly, and a Java guy.. so it might explain it :)

    It’s a bit hard to comment on how useful all those are and whether the distinction makes sense in JS-land since I haven’t used Angular *that* much yet.. but I think you can apply the usual rule here that if something seems too much you probably don’t have to do it.

    I do get the feeling that part of the reason why Angular apps are easy to test is because it has this structure to it, making it easy to inject things and such.

    By Jani Hartikainen on Apr 20, 2013

  11. Good comparison –
    There’s also Knockback http://kmalakoff.github.io/knockback/

    By Rune Jeppesen on May 27, 2013

  1. 1 Trackback(s)

  2. Nov 5, 2013: Using AngularJS for fast prototyping | CodeUtopia - The blog of Jani Hartikainen

Post a Comment

You can use some HTML (a, em, strong, etc.). If you want to post code, use <pre lang="PHP">code here</pre> (you can replace PHP with the language you are posting)