Why does knockout.js have a reputation for being better for small projects, backbone.js for big?

Question

I've been using knockout.js for a few months, and find it a daily joy to use. The gains from not having to manage state on the dom or apply your own custom bindings is incredible, and I don't mind not having out of the box model features. But every time I read an over-view of knockout.js vs other frameworks the consensus seems to be that it's great, it results in less code and complexity overall, but it's better suited for smaller projects. This statement is always given as a matter of fact, without much explanation so I'm confused as to what the consensus seems to be. (In fairness I have not used Backbone yet and so don't truly know how they compare)

I've used it on two quite large projects, each with about a dozen models and a dozen view-models or so, and have not seen a problem with it. The only downside I can see vs Backbone in a large project is that you are going to get some non-negligible performance hit for having knockout apply and manage all of the bindings. But is that the main concern or is there something else I'm missing?

Answer 1

From my (short) comparison of Knockout and Backbone:

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.

Personally, I don't like Knockout. I'm not a fan of the MVVM pattern. I prefer Backbone's approach and I spend most of my time working with it. However, I think the "matter-of-fact" opinions on Knockout not being suited for large applications are wrong. You can build very large, complex, and well structured applications with Knockout. But you have to provide all of the structure beyond data binding and models.

Answer 2

You'll find that web application trends, like fashion trends, spark a lot of opinionated discussions. Most of the time, there's no right or wrong answer. But everyone has their own personal style, and you just have to find yours.

Personally, I like both Knockout and Backbone and was pleased to learn that you don't actually have to choose between them; you can use a plugin called "Knockback" which bridges them together nicely.

I enjoy the MVP structure of Backbone, with the declarative bindings of Knockout. I wrote a blog entry about this, with some examples, if you'd like to learn more.

As for the performance hit of Knockout on large complex DOMs, you can work around that by restricting your bindings to specific DOM elements instead of applying globally:

ko.applyBindings(myViewModel, $('#myElement')[0]); 

The [0] at the end is necessary because Knockout expects a DOM element, and not a jQuery object as the 2nd parameter.