我已经使用 knockout.js 几个月了，每天使用它都很开心。不必在 dom 上管理状态或应用您自己的自定义绑定所带来的好处是令人难以置信的，而且我不介意没有开箱即用的模型功能。但是每次我读到 knockout.js 与其他框架的概览时，大家的共识似乎是它很棒，它总体上会减少代码和复杂性，但它更适合较小的项目。这个陈述总是作为事实给出，没有太多解释，所以我对共识似乎是什么感到困惑。（公平地说，我还没有使用过 Backbone，所以不知道它们是如何比较的）
我在两个相当大的项目中使用了它，每个项目都有大约十几个模型和十几个视图模型，并且没有发现它有问题。在大型项目中，我可以看到与 Backbone 相比的唯一缺点是，在应用淘汰赛和管理所有绑定时，您将获得一些不可忽略的性能影响。但这是主要问题还是我还缺少其他东西？
从我对 Knockout 和 Backbone 的（简短）比较：
Knockout 旨在在 HTML 和模型之间提供流畅、易于使用的模型绑定。它的实现和使用模式非常类似于 XAML/Silverlight/WPF（考虑到它的来源，这很有意义）。但是，Knockout 不提供模型之外的指导或构造。除了模型和模型绑定之外，开发人员还需要构建结构良好的 JavaScript 应用程序。这通常会导致没有良好 JavaScript 经验的开发人员走上一条糟糕的道路，因为他们没有意识到在使用 Knockout 时需要考虑良好的应用程序结构。当然，这个问题无论如何都不是 Knockout 的错。在许多情况下，这只是对工具提供的内容或如何构建大型 JavaScript 应用程序缺乏了解。
就个人而言，我不喜欢 Knockout。我不是 MVVM 模式的粉丝。我更喜欢 Backbone 的方法，并且我大部分时间都在使用它。但是，我认为关于 Knockout 不适合大型应用程序的“事实”观点是错误的。您可以使用 Knockout 构建非常大、复杂且结构良好的应用程序。但是您必须提供除数据绑定和模型之外的所有结构。
您会发现 Web 应用程序趋势，就像流行趋势一样，会引发很多自以为是的讨论。大多数时候，没有正确或错误的答案。但是每个人都有自己的个人风格，你只需要找到你的。
就个人而言，我喜欢 Knockout 和 Backbone，并且很高兴得知您实际上不必在它们之间进行选择；您可以使用一个名为“Knockback”的插件，将它们很好地连接在一起。
我喜欢 Backbone 的 MVP 结构，以及 Knockout 的声明式绑定。 如果您想了解更多信息，我写了一篇关于此的博客文章，并附有一些示例。
至于 Knockout 对大型复杂 DOM 的性能影响，您可以通过限制绑定到特定 DOM 元素而不是全局应用来解决这个问题：
ko.applyBindings(myViewModel, $('#myElement')[0]);
最后的 [0] 是必要的，因为 Knockout 需要一个 DOM 元素，而不是 jQuery 对象作为第二个参数。
大型 javascript 应用程序的代码组织是一个具有挑战性的问题，并且完全独立于您使用的框架 - 除非该框架提供了很多自以为是的结构。
考虑到 Backbone.js 和 Knockout.js 都没有推荐的目录结构，或者推荐的生命周期管理方法，并且任何一个相对于另一个缺少的功能都可以用社区支持的插件或独立的微框架来填补，这真的没有意义在应用的规模/复杂性方面考虑一个优于另一个。
附带说明一下，如果目前开始使用大型 javascript 应用程序，如果您更喜欢声明性方法、基于 DOM 属性的数据绑定和 MVVM 模式，则使用 Angular.js 可能比 Knockout.js 更适合，而 Ember.js 可能如果您更喜欢 MVC 和基于字符串的（Handlebars）模板，则比 Backbone.js 更适合。两者都在积极开发中，并且在功能方面并肩比较，并且专门设计用于缓解人们在使用以前出现的 Backbone 和 Knockout 等较小框架的大型应用程序时所面临的问题。