为什么knockout.js有一个更好的小项目，backbone.js的声誉大？
我已经使用了几个月的knockout.js，并且觉得每天使用它都很愉快。 不必pipe理dom状态或应用自己的自定义绑定所带来的收益是不可思议的，我不介意没有开箱即用的模型function。 但是，每次我阅读一下knockout.js和其他框架的概念，大家一致认为它是好的，它会减less代码和复杂性，但是它更适合于较小的项目。 这个陈述总是作为一个事实给予的，没有太多的解释，所以我对这个共识似乎是什么感到困惑。 （公平地说，我还没有使用骨干，所以不真正知道他们如何比较）
我用了两个相当大的项目，每个都有十几个模型和十几个视图模型，还没有看到问题。 在一个大型的项目中，我唯一能看到vs Backbone的缺点是，你将会得到一些不可忽视的性能，因为有knockout应用和pipe理所有的绑定。 但是，这是主要关心还是有什么我失踪？
从我的（简短） 比较挖空和骨干 ：
Knockout的目标是在HTML和Model之间提供简洁易用的模型绑定。 这是非常像XAML / Silverlight / WPF的实现和使用模式（这是有道理的，考虑它来自哪里）。 尽pipe如此，淘汰赛并不能提供模型之外的指导或构造。 开发人员需要在模型和模型绑定之外构build结构良好的JavaScript应用程序。 这经常会导致开发人员没有良好的JavaScript体验，因为他们没有意识到使用Knockout时需要考虑良好的应用程序结构。 当然，这个问题不是以任何方式击倒的。 在很多情况下，这只是对工具提供的内容缺乏了解，或者缺乏对如何构build大型JavaScript应用程序的理解。
就个人而言，我不喜欢淘汰赛。 我不是MVVM模式的粉丝。 我更喜欢Backbone的方法，我花了大部分时间来处理它。 但是，我认为Knockout的“事实上”的意见不适合大型应用程序是错误的。 您可以使用Knockout构build非常庞大，复杂且结构良好的应用程序。 但是你必须提供数据绑定和模型之外的所有结构。
你会发现networking应用的趋势，如时尚趋势，引发了很多有见地的讨论。 大多数时候，没有对错的答案。 但每个人都有自己的风格，你只需要find你的。
就我个人而言，我喜欢Knockout和Backbone，很高兴知道你实际上并不需要在它们之间做出select。 你可以使用一个名为“Knockback”的插件，将它们很好地连接在一起。
我喜欢Backbone的MVP结构，以及Knockout的声明性绑定。 我写了一个关于这个的博客文章 ，举一些例子，如果你想了解更多。
至于Knockout在大型复杂DOM上的性能问题，您可以通过限制绑定到特定DOM元素而不是全局应用来解决这个问题。
ko.applyBindings(myViewModel, $('#myElement')[0]); 最后的[0]是必要的，因为Knockout需要一个DOM元素，而不是一个jQuery对象作为第二个参数。
大规模的JavaScript应用程序的代码组织是一个具有挑战性的问题，并且完全独立于你使用的框架 – 除非框架提供了很多自以为是的结构。
考虑到Backbone.js和Knockout.js都没有推荐目录结构，或推荐的生命周期pipe理方法，并且任何一个关于另一个的缺失function都可以使用社区支持的插件或独立的微框架来填充，在考虑在应用的大小/复杂性方面优于另一个。
在附注中，如果您现在正在开始使用大规模的JavaScript应用程序，那么如果您更喜欢声明式方法，基于DOM属性的数据绑定和MVVM模式，那么使用Angular.js可能比Knockout.js更适合，而Ember.js可能比起Backbone.js更适合，如果你喜欢MVC和基于string（Handlebars）模板。 两者都在积极开发中，并且在function方面相互比较，并且专门devise用于缓解人们面临的问题，这些问题是在前面提到的像Backbone和Knockout这样的较小的框架下进行的。
