为什么淘汰赛.js以擅长小项目、骨干.js大项目而闻名

Why does knockout.js have a reputation for being better for small projects, backbone.js for big?

本文关键字：js 项目 骨干 小项目 淘汰赛 为什么      更新时间：2023-09-26

我已经使用KNOCKOUT.js几个月了，发现每天使用起来都很开心。 不必在 dom 上管理状态或应用自己的自定义绑定的好处令人难以置信，我不介意没有开箱即用的模型功能。 但是每次我阅读 KNOCKOUT 与其他框架的概述时.js共识似乎是它很棒，它导致更少的代码和整体复杂性，但它更适合较小的项目。 这种说法总是作为事实给出的，没有太多解释，所以我对共识似乎是什么感到困惑。 （公平地说，我还没有使用过Backbone，所以不知道它们是如何比较的）

我已经在两个相当大的项目中使用了它，每个项目都有大约十几个模型和十几个视图模型左右，并且没有看到它的问题。 在一个大型项目中，我能看到的唯一缺点是，对于应用和管理所有绑定，您将受到一些不可忽视的性能影响。但这是主要问题还是我错过了其他东西？

从我对淘汰赛和骨干网的（简短）比较中：

Knockout旨在为HTML和模型之间提供光滑，易于使用的模型绑定。它非常像 XAML/Silverlight/WPF，就像它的实现和使用模式一样（考虑到它的来源，这是有道理的）。但是，敲除不会提供模型之外的指导或构造。由开发人员来构建结构良好的JavaScript应用程序，而不是模型和模型绑定。这通常会导致没有良好JavaScript经验的开发人员走上一条糟糕的道路，因为他们没有意识到在使用Knockout时需要考虑良好的应用程序结构。当然，这个问题无论如何都不是Knockout的错。在许多情况下，这只是缺乏对该工具提供的内容或如何构建大型JavaScript应用程序的理解。

就个人而言，我不喜欢淘汰赛。我不喜欢 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应用程序开始，使用Angular.js可能比Knockout更适合.js如果你更喜欢声明式方法，DOM基于属性的数据绑定和MVVM模式，而Ember.js可能比Backbone更适合.js如果你更喜欢MVC和基于字符串的（Handlebars）模板。两者都在积极开发中，并在功能方面并肩比较，并且专门设计用于缓解人们在使用具有较小框架（如Backbone和Knockout）的大型应用程序时所面临的问题。

相关文章：