javascript - 为什么 knockout.js 以更适合小项目而 backbone.js 更适合大项目而著称？

Question

我已经使用 knockout.js 几个月了，发现每天使用它都是一种乐趣。不必在 dom 上管理状态或应用您自己的自定义绑定(bind)所带来的好处是令人难以置信的，而且我不介意没有开箱即用的模型功能。但每次我读到 knockout.js 与其他框架的对比时，大家的共识似乎是它很棒，它总体上减少了代码和复杂性，但它更适合小型项目。这个声明总是作为事实给出，没有太多解释，所以我对共识似乎是什么感到困惑。 (公平地说，我还没有使用过 Backbone，所以不知道它们之间的比较)

我已经在两个相当大的项目中使用过它，每个项目都有大约十几个模型和十几个 View 模型，并且没有发现任何问题。在大型项目中，我可以看到与 Backbone 相比的唯一缺点是，您将因应用 knockout 和管理所有绑定(bind)而获得一些不可忽略的性能损失。但这是主要问题还是我还遗漏了什么？

Answer 1

来 self 的(短)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.

就我个人而言，我不喜欢 Knockout。我不喜欢 MVVM 模式。我更喜欢 Backbone 的方法，而且我大部分时间都在使用它。但是，我认为关于 Knockout 不适合大型应用程序的“事实”观点是错误的。您可以使用 Knockout 构建非常大、复杂且结构良好的应用程序。但是您必须提供数据绑定(bind)和模型之外的所有 结构。