Javascript 为什么knockout.js 以更适合小型项目而闻名，而backbone.js 适合大型项目？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/10320074/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Why does knockout.js have a reputation for being better for small projects, backbone.js for big?
提问by Jeremy Smith
I've been using knockout.js for a few months, and find it a daily joy to use. The gains from not having to manage state on the dom or apply your own custom bindings is incredible, and I don't mind not having out of the box model features. But every time I read an over-view of knockout.js vs other frameworks the consensus seems to be that it's great, it results in less code and complexity overall, but it's better suited for smaller projects. This statement is always given as a matter of fact, without much explanation so I'm confused as to what the consensus seems to be. (In fairness I have not used Backbone yet and so don't truly know how they compare)
我已经使用knockout.js 几个月了，并且发现每天使用它是一种乐趣。不必管理 dom 上的状态或应用您自己的自定义绑定的好处是难以置信的，而且我不介意没有开箱即用的模型功能。但是每次我读到关于 Knockout.js 与其他框架的概述时，人们的共识似乎是它很棒，它总体上减少了代码和复杂性，但它更适合较小的项目。这个声明总是作为事实给出的，没有太多解释，所以我对共识似乎是什么感到困惑。（公平地说，我还没有使用 Backbone，所以不知道它们如何比较）
I've used it on two quite large projects, each with about a dozen models and a dozen view-models or so, and have not seen a problem with it. The only downside I can see vs Backbone in a large project is that you are going to get some non-negligible performance hit for having knockout apply and manage all of the bindings. But is that the main concern or is there something else I'm missing?
我已经在两个相当大的项目中使用了它，每个项目都有大约十几个模型和十几个视图模型，并且没有发现它的问题。在一个大型项目中，我看到与 Backbone 相比的唯一缺点是，您将获得一些不可忽视的性能损失，因为应用淘汰赛和管理所有绑定。但这是主要问题还是我还缺少其他东西？
回答by Derick Bailey
From my (short) comparison of Knockout and Backbone:
从我对 Knockout 和 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 旨在在 HTML 和模型之间提供灵活、易于使用的模型绑定。它的实现和使用模式非常像 XAML/Silverlight/WPF（考虑到它的来源，这是有道理的）。但是，Knockout 不提供模型之外的指导或构造。开发人员可以在模型和模型绑定之外构建结构良好的 JavaScript 应用程序。这通常会导致没有良好 JavaScript 经验的开发人员走上糟糕的道路，因为他们没有意识到在使用 Knockout 时需要考虑良好的应用程序结构。当然，这个问题无论如何都不是 Knockout 的错。在许多情况下，这只是缺乏对该工具提供的功能或如何构建大型 JavaScript 应用程序的理解。
Personally, I don't like Knockout. I'm not a fan of the MVVM pattern. I prefer Backbone's approach and I spend most of my time working with it. However, I think the "matter-of-fact" opinions on Knockout not being suited for large applications are wrong. You can build very large, complex, and well structured applications with Knockout. But you have to provide allof the structure beyond data binding and models.
就个人而言，我不喜欢淘汰赛。我不喜欢 MVVM 模式。我更喜欢 Backbone 的方法，我大部分时间都在使用它。但是，我认为关于 Knockout 不适合大型应用程序的“事实”意见是错误的。您可以使用 Knockout 构建非常大、复杂且结构良好的应用程序。但是您必须提供除数据绑定和模型之外的所有结构。
回答by Dave Cadwallader
You'll find that web application trends, like fashion trends, spark a lot of opinionated discussions. Most of the time, there's no right or wrong answer. But everyone has their own personal style, and you just have to find yours.
您会发现 Web 应用程序趋势，如时尚趋势，引发了很多固执己见的讨论。大多数时候，没有正确或错误的答案。但每个人都有自己的个人风格，你只需要找到你的。
Personally, I like both Knockout and Backbone and was pleased to learn that you don't actually have to choose between them; you can use a plugin called "Knockback" which bridges them together nicely.
就个人而言，我喜欢 Knockout 和 Backbone，并且很高兴得知您实际上不必在它们之间做出选择；您可以使用一个名为“Knockback”的插件，它可以很好地将它们连接在一起。
I enjoy the MVP structure of Backbone, with the declarative bindings of Knockout. I wrote a blog entry about this, with some examples, if you'd like to learn more.
我喜欢 Backbone 的 MVP 结构，以及 Knockout 的声明式绑定。 如果您想了解更多信息，我写了一篇关于此的博客条目，并附有一些示例。
As for the performance hit of Knockout on large complex DOMs, you can work around that by restricting your bindings to specific DOM elements instead of applying globally:
至于 Knockout 在大型复杂 DOM 上的性能影响，您可以通过将绑定限制到特定 DOM 元素而不是全局应用来解决这个问题：
ko.applyBindings(myViewModel, $('#myElement')[0]);
The [0] at the end is necessary because Knockout expects a DOM element, and not a jQuery object as the 2nd parameter.
最后的 [0] 是必需的，因为 Knockout 需要一个 DOM 元素，而不是一个 jQuery 对象作为第二个参数。
回答by lorefnon
Code organization of large scale javascript applications is a challenging problem and is quite independent of which framework you use - unless the framework provides a lot of opinionated structuring.
大型 javascript 应用程序的代码组织是一个具有挑战性的问题，并且与您使用的框架完全无关 - 除非该框架提供了很多自以为是的结构。
Considering neither Backbone.js nor Knockout.js have recommended directory structure, or recommended lifecycle management methodology and whatever missing functionality is there in one with respect to another can be filled in with community supported plugins or stand-alone microframeworks, there is seriously no point in considering one as superior to another in the context of size/complexity of application.
考虑到 Backbone.js 和 Knockout.js 都没有推荐的目录结构，或者推荐的生命周期管理方法，而且无论一个相对于另一个缺失的功能都可以用社区支持的插件或独立的微框架来填补，这真的没有意义在应用程序的大小/复杂性的背景下考虑一个优于另一个。
On a side note if one is starting with a large scale javascript application at present, using Angular.js may be more suited than Knockout.js if you prefer declarative approach, DOM attribute based data-binding and MVVM pattern, and Ember.js may be more suited than Backbone.js if you prefer MVC and string based (Handlebars) templates. Both are in active development and compare shoulder to shoulder with respect to features, and were specifically designed to ease the problems people have been facing working with large applications with smaller frameworks like Backbone and Knockout, that came before.
附带说明一下，如果您目前正在从大型 javascript 应用程序开始，如果您更喜欢声明式方法、基于 DOM 属性的数据绑定和 MVVM 模式，则使用 Angular.js 可能比 Knockout.js 更适合，而 Ember.js 可能如果您更喜欢 MVC 和基于字符串的（把手）模板，那么它比 Backbone.js 更适合。两者都在积极开发中，并且在功能方面并肩比较，并且专门设计用于缓解人们在使用小型框架（如 Backbone 和 Knockout）的大型应用程序工作时遇到的问题。
