Why does knockout.js have a reputation for being better for small projects, backbone.js for big?
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?
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.
document.getElementById('myElement'). jQuery is nice, but no sense using it just to immediately extract the raw element.
Backbone.setDomLibrary = function(lib) { $ = lib; };
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.
Follow WeChat
Success story sharing
