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