为什么knockout.js在小型项目中更有声誉,为大型项目提供backbone.js？

Question

我一直在使用knockout.js几个月,并发现它每天都很愉快.无需在dom上管理状态或应用自己的自定义绑定所带来的收益是令人难以置信的,我不介意没有开箱即用的模型功能.但每当我阅读knockout.js与其他框架的概述时,共识似乎是它很棒,它会导致整体代码和复杂性降低,但它更适合小型项目.这个陈述总是在事实上给出,没有太多解释,所以我对共识似乎是什么感到困惑.(公平地说,我还没有使用Backbone,所以不能真正知道他们如何比较)

我已经在两个相当大的项目中使用它,每个项目都有大约十几个模型和十几个视图模型左右,并且没有看到它的问题.在一个大型项目中,我可以看到与Backbone相比唯一的缺点是,你可以获得一些不可忽视的性能,因为它可以应用于淘汰赛并管理所有绑定.但这是主要问题还是我还缺少其他东西？

Answer 1

从我对Knockout和Backbone的(简短)比较:

Knockout旨在为HTML和Model之间提供灵活,易用的模型绑定.它的XAML/Silverlight/WPF就像它的实现和使用模式一样(考虑到它的来源,这是有道理的).但是,Knockout不提供模型之外的指导或构造.开发人员可以在模型和模型绑定之外构建结构良好的JavaScript应用程序.这往往导致开发人员没有良好的JavaScript经验,因为他们没有意识到他们在使用Knockout时需要考虑良好的应用程序结构.当然这个问题不是Knockout的错误.在很多情况下,这只是缺乏对工具提供的内容或如何构建大型JavaScript应用程序的理解.

就个人而言,我不喜欢Knockout.我不是MVVM模式的粉丝.我更喜欢Backbone的方法,我花了大部分时间来处理它.但是,我认为Knockout上的"事实上的"观点不适合大型应用程序是错误的.您可以使用Knockout构建非常大,复杂且结构良好的应用程序.但是你必须提供除数据绑定和模型之外的所有结构.

Answer 2

你会发现网络应用程序的趋势,如时尚潮流,引发了很多自以为是的讨论.大多数时候,没有正确或错误的答案.但每个人都有自己的个人风格,你只需找到你的.

就个人而言,我喜欢Knockout和Backbone,很高兴得知你实际上不必在它们之间做出选择; 你可以使用一个名为"Knockback"的插件,将它们很好地连接在一起.

我喜欢Backbone的MVP结构,带有Knockout的声明性绑定. 如果你想了解更多,我写了一篇关于这个的博客文章和一些例子.

至于Knockout在大型复杂DOM上的性能影响,你可以通过限制绑定到特定DOM元素而不是全局应用来解决这个问题:

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

最后的[0]是必要的,因为Knockout需要一个DOM元素,而不是jQuery对象作为第二个参数.