为什么knockout.js因小型项目而出名，backbone.js适合大型项目？

Question

我几个月来一直在使用knockout.js，并且发现它每天使用的乐趣。无需在dom上管理状态或应用自己的自定义绑定所带来的收益是令人难以置信的，我不介意不具备开箱即用的模型功能。但是，每次我阅读了对knockout.js和其他框架的概述之后，我们的共识似乎是非常好的，它会减少整体代码和复杂性，但它更适合于较小的项目。这个陈述总是作为事实给出的，没有太多的解释，所以我对共识似乎是什么感到困惑。 （公平地说，我还没有使用骨干，所以不真正知道他们是如何比较）

我已经用它在两个相当大的项目，每个有大约十几个模型和十几个视图模型左右，并没有看到它的问题。在一个大型项目中，我可以看到vs Backbone的唯一不足之处在于，您将获得一些不可忽视的性能，因为它会应用并管理所有绑定。但是，这是主要关心还是有什么我失踪？

Answer 1

从我的（短）comparison of Knockout and Backbone：

淘汰赛旨在提供光滑，易于使用的HTML和模型之间的模型绑定。这是非常类似于XAML/Silverlight/WPF的实现和使用模式（这很有道理考虑它来自哪里）。尽管如此，淘汰赛并不提供模型之外的指导或构造。开发人员需要在模型和模型绑定之外构建结构良好的JavaScript应用程序。这经常会导致开发人员没有良好的JavaScript体验，因为他们没有意识到使用Knockout时需要考虑良好的应用程序结构。当然，这个问题不是以任何方式击倒的缺点。在很多情况下，这只是对该工具提供的内容缺乏了解，或者缺乏对如何构建大型JavaScript应用程序的理解。

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

Answer 2

你会发现网络应用的趋势，如时尚趋势，引发了很多有见地的讨论。大多数时候，没有正确或错误的答案。但每个人都有自己的个人风格，你只需要找到你的。

就我个人而言，我喜欢Knockout和Backbone，很高兴知道您实际上不必在两者之间进行选择;您可以使用名为“Knockback”的插件将它们很好地连接在一起。

我喜欢Backbone的MVP结构，并带有Knockout的声明性绑定。 I wrote a blog entry about this，以及一些示例，如果您想了解更多信息。

至于淘汰赛的表现打在大型复杂的DOM，你可以解决通过限制您的绑定到特定的DOM元素，而不是全局应用：

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

的[0]到底是必要的因为Knockout需要一个DOM元素，而不是作为第二个参数的jQuery对象。

Answer 3

大型JavaScript应用程序代码组织是一个具有挑战性的问题，是完全独立的，你使用的框架 - 除非该框架提供了很多自以为是的结构化。

考虑到Backbone.js和Knockout.js都没有推荐目录结构或推荐的生命周期管理方法，并且可以使用社区支持的插件或独立的微框架填充任何缺少的功能，认为在应用的规模/复杂性背景下优于另一个是严肃的。

在附注中，如果您现在正在开始使用大规模JavaScript应用程序，那么如果您更喜欢使用声明式方法，基于DOM属性的数据绑定和MVVM模式，那么使用Angular.js可能比Knockout.js更适合;如果您更喜欢MVC和基于字符串（Handlebars）模板，Ember.js可能比Backbone.js更适合。两者都在积极开发中，并且在功能方面进行了比较，并且专门设计用于缓解人们面临的问题，这些问题与前面介绍的像Backbone和Knockout这样的小型框架一起处理大型应用程序。