Backbone vs Knockout

There’s an unfortunate dichotomy of “Backbone vs Knockout” floating around these days. It’s mostly in the .NET space where Knockout tends to get the most attention but I’ve heard others mention this, too. It’s an unfortunate argument, though. Both libraries are great, both are very powerful and both solve different problems in the front-end development space. The major difference between the two is the focus of each.

Strengths And Weaknesses

Knockout aims to provide slick, easy to use model bindings between the HTML and Model. It’s very XAML/Silverlight/WPF like in it’s implementation and usage patterns (this makes sense considering where it came from). Knockout does not provide guidance or constructs beyond the model, though. It’s up to the developers to build well structured JavaScript applications beyond the models and model bindings. This often leads developers without good JavaScript experience down a bad path because they don’t realize that they need to consider good application structure when using Knockout. Of course this problem is not the fault of Knockout by any means. It’s simply a lack of understanding of what the tool provides, or how to structure large JavaScript apps, in many cases.

Backbone, on the other hand, takes a “good JavaScript app architecture” approach. It focuses on providing constructs that can be used to organize your code in meaningful ways. One thing to note about Backbone is that it’s not a heavy-handed, prescriptive MVC framework. In truth, it fits within the MV* families, but is not MVC or MVVM or any other specific variant. It takes ideas from a lot of these variants and provides a library of constructs that can be used when needed, without requiring the use of any of them. This is one of the reasons I’ve stuck with Backbone – it’s flexible. It lets me use only a View when I want to, or only a Model when I want to. Unlike Knockout, Backbone does not directly address the model binding space. It provides plenty of hooks and open / flexibility in it’s design and implementation, though, allowing model binding to be integrated in to it.

Model Binding

It really is a shame that there is such a “Backbone vs Knockout” mentality when these tools should play together and create an even better experience for the developer and end-user. The big problem has been that they clobber each other when it comes to the idea of a “model”. However, Knockout’s recent releases have an API that can be used to bind anything to Knockout. With that, here’s a project up on Github that brings both KO and BB together:

There’s also my own Backbone.ModelBinding plugin which aims to bring a lot of model binding capabilities to Backbone without using Knockout (while being heavily inspired by it):

Knockout -> Backbone

For what it’s worth: I know a handful of people that start with Knockout because of the astounding demos and jaw-dropping ease of creating model bindings. After building some very large JavaScript apps, though, they wished that they had gone with something like Backbone which provides a better structure out of the box for large apps. I’m not saying you can’t built large JavaScript apps with Knockout. You have to build the infrastructure or find another infrastructure to support the large app design needs, though.

Knockout AND Backbone

With Knockback bringing both of these projects together, maybe you don’t need to choose one or the other for the system at large. Maybe you can get down to choosing which one is right for the specific page your building, including both of them when needed.

About Derick Bailey

Derick Bailey is an entrepreneur, problem solver (and creator? :P ), software developer, screecaster, writer, blogger, speaker and technology leader in central Texas (north of Austin). He runs - the amazingly awesome podcast audio hosting service that everyone should be using, and where he throws down the JavaScript gauntlets to get you up to speed. He has been a professional software developer since the late 90's, and has been writing code since the late 80's. Find me on twitter: @derickbailey, @mutedsolutions, @backbonejsclass Find me on the web: SignalLeaf, WatchMeCode, Kendo UI blog, MarionetteJS, My Github profile, On Google+.
This entry was posted in Backbone, Javascript, Knockout. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • I’ve used Knockout a bit, haven’t used Backbone yet. My current take  is that Knockout is great for single-page usage, where you need to add some interactivity and don’t want a ton of manual jquery event handlers all through your code. For an _application_ however, I think I’d want to investigate Backbone.

    Does this characterization fit with your experience with both?

    • Yeah – that fits right in line with how I see them. Although I can image some KO fans saying otherwise. :)

      I debated including something similar in the post but decided to keep the post shorter and more focused on the real issue of “AND vs OR”. 

  • Anonymous

    I can say that I’ve used both in large JavaScript applications. I have to completely agree with what Derick highlights in this post. Both are very good libraries and their powers can be harnessed to bring a lot of power to any frontend Dev.

    I too agree that if a team is inexperienced with building large client side apps the knockout approach will not provide any app structure opinions and thus could result in a badly designed app. However, this isn’t because of KO, it’s the dev’s fault.

    I personally enjoy backbone’s opinionated approach as it provides a team lead a place to direct novice js app devs (or at least novice to large js app design) for app design.

    At the moment I’m enjoying working with reauireJS

  • Mike Fielden Jr.

    Great article. I also started with KO and thought it to be a bit heavy handed for my use. I immediately looked into Backbone and love it. For me its the goldilocks of JS frameworks (so far).

  • Anonymous

    May I casually suggest having a look at Batman? Full disclosure, I’m a core developer.

    Batman aims to be a knockout with more imposed structure, a la backbone. It has a full fledged binding system, but it extends throughout the whole library allowing you to bind your views to server side data through models or ephemeral data like controller variables. We also really want to give devs a common baseline for how to organize their apps, and some strong core classes with useful, reliable conventions. 

    Let me know if Batman floats your boat, and if not, what we could do better!

    •  And let’s not forget SproutCore 2.0 and Derby :)

    • Just off the cuff, my only problem (and, admittedly, it’s pretty minor) is that the entire documentation is in CoffeeScript.  Sure I could go run things through the coffee compiler, but wouldn’t it be nice to embed that in the docs and give people a choice of which version they’d like to see (maybe as tabs on each sample, like MSDN)?

  • ju

    I’ve used both although I know and use mostly Backbone, as a binding solution (with some minor changes) I use binder js ( and it does the job fine, I think both of these frameworks are really awesome tools for JS development

  • As  Backbone user, your backbone.modelbindings extension has been a huge time saver for me.   Saw this post and thought I’d take the time to thank you.  So, thanks!

  • This is interesting, never really thought of them as competitors. I always saw it as Backbone vs Spine. None the less, good read!

  • Your backbone.modelbindings extension sounds really cool !

    By the way, what do you think about using JsViews with Backbone.js ( ?

  • I personally reviewed these 2 frameworks, and ended up choosing a third – JavascriptMVC. I think it’s a shame it gets the least amount of love from the JS community, it deserves much more. 

    The dealbreaker in Backbone for me was that it doesn’t offer and isn’t built on a class model. Backbone fans usually use it together with Coffeescript to get class functionality. In JMVC there’s a strong Class model built on John Resig’s suggested implementation.

  • Both of these are well done, but it seems to me that much of MVC type architectures can not only be implemented in JavaScript without the help of a framework, but the resulting code can be cleaner and more performant. There are plenty of small libraries to do things like PubSub, etc., or you can write your own. Much of this comes down to mindset rather than what framework, if any, you choose.

  • I’m mainly working as a back end developer doing all the server side stuff. For the client app part i’ve tried knockout and was very pleased. Backbone is the next part on my list, because i think they can complement each other. 

    In my opinion one of the main reasons why there is a x vs y mentality is because you mostly find tutorials where framework x or y is deified. There should be more resources that show how to build good apps using different frameworks togehter.

  • Abhilash P

    Thanks for the simple explanation….

  • Tired of Know It Alls

    You know
    Derick, maybe if you provided some real world DEMOS and not theoretical rants on your hit hub, I might be inclined to believe you. So far I have not seen ONE, NOT ONE actually working demo of yours on Backbone relative to relational models. I’ll pass therefore on your opinions.

  • Very good informative post that you have shared and thankful your work for sharing the information. Got some entertaining information and would like to give it a try. Appreciate your work and keep sharing your information