爲什麼knockout.js因小型項目而出名，backbone.js適合大型項目？

Question

我幾個月來一直在使用knockout.js，並且發現它每天使用的樂趣。無需在dom上管理狀態或應用自己的自定義綁定所帶來的收益是令人難以置信的，我不介意不具備開箱即用的模型功能。但是，每次我閱讀了對knockout.js和其他框架的概述之後，我們的共識似乎是非常好的，它會減少整體代碼和複雜性，但它更適合於較小的項目。這個陳述總是作爲事實給出的，沒有太多的解釋，所以我對共識似乎是什麼感到困惑。 （公平地說，我還沒有使用骨幹，所以不真正知道他們是如何比較）

我已經用它在兩個相當大的項目，每個有大約十幾個模型和十幾個視圖模型左右，並沒有看到它的問題。在一個大型項目中，我可以看到vs Backbone的唯一不足之處在於，您將獲得一些不可忽視的性能，因爲它會應用並管理所有綁定。但是，這是主要關心還是有什麼我失蹤？

Answer 1

從我的（短）comparison of Knockout and Backbone：

淘汰賽旨在提供光滑，易於使用的HTML和模型之間的模型綁定。這是非常類似於XAML/Silverlight/WPF的實現和使用模式（這很有道理考慮它來自哪裏）。儘管如此，淘汰賽並不提供模型之外的指導或構造。開發人員需要在模型和模型綁定之外構建結構良好的JavaScript應用程序。這經常會導致開發人員沒有良好的JavaScript體驗，因爲他們沒有意識到使用Knockout時需要考慮良好的應用程序結構。當然，這個問題不是以任何方式擊倒的缺點。在很多情況下，這只是對該工具提供的內容缺乏瞭解，或者缺乏對如何構建大型JavaScript應用程序的理解。

就我個人而言，我不喜歡淘汰賽。我不是MVVM模式的粉絲。我更喜歡Backbone的方法，並且我大部分時間都在使用它。但是，我認爲關於Knockout的「事實上的」意見不適合大型應用程序是錯誤的。您可以使用Knockout構建非常龐大，複雜且結構良好的應用程序。但是你必須提供所有的以外的數據綁定和模型。

Answer 2

你會發現網絡應用的趨勢，如時尚趨勢，引發了很多有見地的討論。大多數時候，沒有正確或錯誤的答案。但每個人都有自己的個人風格，你只需要找到你的。

就我個人而言，我喜歡Knockout和Backbone，很高興知道您實際上不必在兩者之間進行選擇;您可以使用名爲「Knockback」的插件將它們很好地連接在一起。

我喜歡Backbone的MVP結構，並帶有Knockout的聲明性綁定。 I wrote a blog entry about this，以及一些示例，如果您想了解更多信息。

至於淘汰賽的表現打在大型複雜的DOM，你可以解決通過限制您的綁定到特定的DOM元素，而不是全局應用：

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

的[0]到底是必要的因爲Knockout需要一個DOM元素，而不是作爲第二個參數的jQuery對象。

Answer 3

大型JavaScript應用程序代碼組織是一個具有挑戰性的問題，是完全獨立的，你使用的框架 - 除非該框架提供了很多自以爲是的結構化。

考慮到Backbone.js和Knockout.js都沒有推薦目錄結構或推薦的生命週期管理方法，並且可以使用社區支持的插件或獨立的微框架填充任何缺少的功能，認爲在應用的規模/複雜性背景下優於另一個是嚴肅的。

在附註中，如果您現在正在開始使用大規模JavaScript應用程序，那麼如果您更喜歡使用聲明式方法，基於DOM屬性的數據綁定和MVVM模式，那麼使用Angular.js可能比Knockout.js更適合;如果您更喜歡MVC和基於字符串（Handlebars）模板，Ember.js可能比Backbone.js更適合。兩者都在積極開發中，並且在功能方面進行了比較，並且專門設計用於緩解人們面臨的問題，這些問題與前面介紹的像Backbone和Knockout這樣的小型框架一起處理大型應用程序。