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

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.

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.

Code organization of large scale javascript applications is a challenging problem and is quite independent of which framework you use - unless the framework provides a lot of opinionated structuring.

Considering neither Backbone.js nor Knockout.js have recommended directory structure, or recommended lifecycle management methodology and whatever missing functionality is there in one with respect to another can be filled in with community supported plugins or stand-alone microframeworks, there is seriously no point in considering one as superior to another in the context of size/complexity of application.

On a side note if one is starting with a large scale javascript application at present, using Angular.js may be more suited than Knockout.js if you prefer declarative approach, DOM attribute based data-binding and MVVM pattern, and Ember.js may be more suited than Backbone.js if you prefer MVC and string based (Handlebars) templates. Both are in active development and compare shoulder to shoulder with respect to features, and were specifically designed to ease the problems people have been facing working with large applications with smaller frameworks like Backbone and Knockout, that came before.