原文連結：Rich JavaScript Applications – the Seven Frameworks 翻譯：李鬆峰
一週前，Throne of JS大會在多倫多召開，這應該是我參加過的最有料也最不一樣的一次大會。大會官網如是說：
載入整個頁面，然後再“漸進增強”以新增動態行為，這種構建Web應用的方式已經不夠好了。要想讓應用載入快，反應靈敏，而且又引領潮流，必須徹底檢討你的開發手段。
這次大會邀請了八大JavaScript框架/庫的建立人，他們濟濟一堂，面對面交流各自的技術理念。所謂八大框架/庫分別是：AngularJS、Backbone、Batman、CanJS、Ember、Meteor、Knockout、Spine。1
宣告：我在會上講Knockout，因此我的觀點顯然不是中立的。在這篇文章中，我重點討論這些建立人的思路和技術理念，儘量不提我贊成或反對什麼。
1 沒錯，是8個框架，不是7個。但到底怎麼回事兒，會議主辦方也沒有明確給我們解釋過……
文章可長啦，先概述一下：
●對許多Web開發人員來說，要構建富Web應用，使用客戶端框架是理所當然的。如果你什麼框架也沒用，那要麼你不是在做應用，要麼就會錯過很多好東西。
●在使用方法上，這些框架很多地方都是一致的（模型-檢視-*架構、宣告繫結，等等——詳見下文） ，因此從某種意義講，無論你選擇哪一個，都能得到同樣的好處。
●理念上還是有不少差異，特別是在對框架和庫的看法上，分歧格外大。你的選擇會深刻影響你的架構。
●會議本身活潑，新穎，技術小組之間有很多交流和對話。我希望能有更多類似的會議。
技術：共識與分歧
隨著每個SPA（Single Page Application，單頁應用）技術的逐一展示，一些相當明顯的相似性和差異性浮出了水面。
共識：漸進增強不能建立真正的應用
各技術門派一致認為，真正的JavaScript應用必須有適當的資料模型，並具備客戶端渲染能力，而絕不僅僅是伺服器處理資料再加上一些Ajax和jQuery程式碼那麼簡單。
用Backbone建立人Jeremy Ashkenas的話說：“現如今，你說‘單頁應用’，都跟說‘不用馬拉的車’差不多了”（意思是，早已經沒那麼新鮮了）。
“不用馬拉的車”（horseless carriage）是汽車剛剛發明的時候，人們對它的稱呼。——譯者注
共識：模型-檢視-某某
所有技術門派都堅持模型－檢視分離。有的強調MVC（Model View Control），有的提到MVVM（Model View ViewModel），甚至有人拒絕明確說出第三個詞兒（只提模型、檢視，然後加上讓它們協調運作的東西）。對各門派而言，最終結果其實是相似的。
共識：推崇資料繫結
除了Backbone和Spine之外，其他框架都在自己的檢視裡內建了宣告資料繫結的機制（Backbone的設計理念強調讓使用者“自選檢視技術”）。
共識：IE6已死
在小組討論中，大多數框架的建立者說，他們對IE瀏覽器的支援只限於7+（事實上，Ember和AngularJS的起點是IE8，Batman需要ES5“墊片”才能在IE9之前的IE版本中使用）。這也是大勢所趨：jQuery 2已經不打算支援IE9以下的舊版本IE了。
只有Backbone和Knockout還堅定支援IE6+（我不清楚Backbone的內部實現，但Knockout會把IE6/7那些令人抓狂的渲染及事件方面的怪異行為遮蔽掉）。
共識：許可和原始碼控制
大家都使用MIT許可，並且託管在GitHub上。
分歧：庫與框架
這是目前最大的分歧。下表對JavaScript庫和框架進行了歸類：
| JavaScript庫 | JavaScript框架 |
|---|---|
| Backbone（9552） | Ember（3993） |
| Knockout（2357） | AngularJS（2925） |
| Spine（2017） | Batman（958） |
| CanJS（321） | Meteor（4172）——了不起，見下文 |
**括號中的數字是最近某個時間點GitHub上的關注者數量，粗略地代表各自的影響力。*
什麼意思呢？
●JavaScript庫，插到既有架構中，補充特定功能。
●JavaScript框架，提供一個架構（檔案結構啊，等等），你必須遵守它，只要你遵守，那剩下的就全都是處理通用需求了。
目前來看，鼓吹框架模型最賣力氣的是Ember，其建立人Yehuda Katz之前是（理念相似的）Rails和SproutCore專案的開發者。他的觀點是，缺少任何元件都不夠給力，都不能說是真正在推動技術進步。相反的觀點說，庫的目的更明確，因而更容易掌握、採用、定製，也有助於把專案風險降到最低，畢竟你的架構不會嚴重依賴任何一個外部專案。根據我參加對話的情況看，現場觀眾也分成了兩派，有支援框架的，也有支援庫的。
請注意，AngularJS可以說是介於庫和框架之間一種形態：它不要求開發時遵守特定的檔案組織方式（與庫類似），但在執行時，它提供一個“應用生命週期”，可以對號入座地把程式碼安排進去（與框架類似）。之所以把它歸入框架之列，是因為AngularJS團隊樂於接受這個說法。
分歧：靈活，還是整合
每個技術門派都有不同程度的強制性規定：
| 檢視 | URL路由 | 資料儲存 | |
|---|---|---|---|
| AngularJS | 內建基於DOM的模板（必選） | 內建（可選） | 內建系統（可選） |
| Backbone | 自選（最常用的是基於字串的模板庫handlebars.js） | 內建（可選） | 內建（可重寫） |
| Batman | 內建基於DOM的模板（必選） | 內建（必選） | 內建系統（必選） |
| CanJS | 內建基於字串的模板（必選） | 內建（可選） | 內建（可選） |
| Ember | 內建基於字串的模板（必選） | 內建（必選） | 內建（可重寫） |
| Knockout | 內建基於DOM的模板（可選，也可以用基於字串的模板） | 自選（大都使用sammy.js或history.js） | 自選（如knockout.mapping或只用$.ajax） |
| Meteor | 內建基於字串的模板（必選） | 內建（必選？不確定） | 內建（Mongo，必選） |
| Spine | 自選基於字串的模板 | 內建（可選） | 內建（可選？不確定） |
不難想見，只要某個庫在某方面是開放的，他們的人就會強調只有這樣才能從總體上確保跟第三方庫相容。同樣，顯而易見的反對意見則是，只有內建才能保證無縫整合。再次，根據我參加的對話，現場觀眾也各持己見，說什麼的都有，基本上可以看出每個人對其他技術組合的瞭解程度。
Ember的Tom Dale說：“我們加入了很多魔法，但都是有用的魔法，換句話說，它們可以分解為常規的操作原語。”
分歧：基於字串的模板與基於DOM的模板
（請參考上面的表格。）對基於字串的模板，大家幾乎都選擇Handlebars.js作為模板引擎，它儼然成了這個領域的霸主，當然CanJS用的是EJS。對基於字串的模板，支援的人認為“它更快”（不一定），而且“理論上，伺服器也可以處理它”（也不一定，因為前提必須是在伺服器上執行所有模型程式碼，而實踐中根本沒人那麼做）。
而基於DOM的模板呢，意味著純粹通過在實際標記中繫結來控制流程（each、if，等等），且不依賴任何外部模板庫。支援的聲音有“它更快”（不一定），另外“程式碼易讀、易寫，且標記與模板之間沒有隔閡，CSS如何與之互動也一目瞭然。”
在我看來，最有吸引力的說法來自AngularJS那幫傢伙，他們認為在不久的將來，基於DOM的模板會得到瀏覽器原生支援。所以我們最好現在就用，從而可以輕鬆應對未來。AngularJS來自Google，所以他們在開發Chromium時會考慮這一點，而且也會說服標準主體接納這個建議。
分歧：伺服器中立到什麼程度
Batman和Meteor明顯依賴伺服器：Batman是為Rails設計的，而Meteor本身就是伺服器。其他大多數都追求伺服器中立。但實際上，Ember的架構、強制性規定，以及某些工具都傾向於Rails開發者。當然，Ember絕對也能跟其他伺服器技術搭配，只不過眼下還需要較多手工配置。
技術門派概覽
以下是所有JavaScript庫/框架的基本技術細節。
Backbone
●Who: Jeremy Ashkenas和DocumentCloud。
●What:
+ 用JavaScript實現模型-檢視，MIT許可。
+ 只有一個檔案，1000行程式碼，在所有庫中最小！
+ 功能極其專一，只提供REST可持久模型及簡單路由和回撥（以便你知道何時渲染檢視，但檢視渲染機制由你自己選擇）。
+ 名氣最大，很多大牌站點都在用（也許是因為它最小，容易部署）。
●Why:
+ 非常小，使用它之前，你完全可以通讀並理解它的原始碼。
+ 不會影響你的伺服器架構或檔案組織方式。可以在頁面的某一部分內執行——不需要控制整個頁面。
+ Jeremy好像進入了一種禪宗所謂的入定的狀態，對一切都能坦然接受。他就像一個大人，看著一群孩子在那裡辯論。
●When: 至今已誕生近兩年了。
Meteor
●Who: Meteor 開發團隊（他們剛募集到1120萬美元投資，因此可以全職開發）。
●What:
+ 前瞻性極強的一個框架，想不出有誰那麼激進過（也許Derby算一個）。
+ 將一個伺服器端執行時環境（用Node+Mongo搭建）和一個客戶端執行時環境銜接起來，讓你的程式碼在兩端都能執行，還包含資料庫。利用WebSockets實現所有客戶端和伺服器之間的同步。
+ 在修改程式碼時就“實時部署”——客戶端執行時可以即時更新而不丟失狀態。
+ 可以看看這個視訊，對它的認識就會更全面。
+ 跟會上與我有過交流的所有人一樣，我也衷心希望這個框架獲得成功——Web開發就需要這種激進的改革才能真正進步。
●Why: 你實在覺得做常規Web開發太無聊了，想找點刺激。
●When: 誕生時間不長；除了其核心團隊在用，不知道還有沒有其他站點實際在用Meteor。不過，這個團隊真是在嚴肅地做著一件前無古人的事。
Ember
●Who: Yehuda Katz （之前開發過jQuery和Rails）、Ember團隊和Yehuda的公司Tilde。
●What:
+ 構建“超級Web應用”所需的一切，MIT許可。
+ 功能最多，體積最大。
+ 融入了很多設計理念，涉及如何分解並對頁面進行層次控制，以及如何利用一個狀態機驅動的系統聯結各個層次。
+ 正在開發一個功能非常完善的資料訪問庫（Ember.Data）。
+ 要在執行時控制整個頁面，因此不適合開發大頁面上的“富應用區”。
+ 對檔案、URL等都有相當嚴格的一套約束，不過要是不喜歡，你可以重寫，只要你知道怎麼做就OK。
+ 設計靈感來自Rails和Cocoa。
+ 工具：為Rails提供專案模板（但如果你手工編寫程式碼，也可以使用其他伺服器端平臺）。
●Why: 常見的問題應該有通用的解決方案——Ember提供了所有通用解決方案。
●When: 尚未釋出1.0版，但也快了。然後，API基本就能穩定下來。
●AngularJS
●Who: Google（他們內部在使用）。
●What:
+ 用JavaScript實現模型-檢視-其他，MIT許可。
+ 基於DOM的模板，具備可觀察能力、宣告繫結機制，還有準MVVM式的程式碼風格（他們自己說是Model-View-Whatever）
+ 內建基本URL路由和資料持久化能力
+ 工具：附帶一個Chrome偵錯程式外掛，讓你在除錯的時候能夠檢視模型；還附帶一個Jasmine測試框架。
●Why:
+ 從概念上講，他們說這個框架相當於一個“填料層”，蓋在當前瀏覽器上，以實現未來的瀏覽器將可能原生具備的能力（即宣告繫結和可觀察能力）。因此，我們現在就應該著手這麼來寫程式碼了。
+ 對伺服器架構或檔案組織方式沒有影響。可以用在頁面的某一小部分中——不需要控制整個頁面。
●When: 成品級框架，Google已經搞出來有一段時間了。
Knockout
●Who: Knockout 團隊和社群（核心團隊目前有三個人，包括我）。
●What:
+ 用JavaScript實現模型-檢視-檢視模型（MVVM，Model-View-ViewModel），MIT許可。
+ 功能集中在富使用者介面元素：基於DOM的宣告繫結模板，可觀察的模型加自動依賴檢測。
+ 沒有限定URL路由或資料訪問——可組合任意第三方庫（例如，用Sammy.js做路由，用純Ajax實現儲存）。
+ 在降低使用門檻方面下了很大工夫，提供詳盡的文件和互動式示例。
●Why:
+ 只做好一件事（UI），向後相容到IE6。
+ 對伺服器架構或檔案組織方式沒有影響。可以用在頁面的某一小部分中——不需要控制整個頁面。
●When: 到現在已經正式釋出近兩年了。
Spine
●Who: Alex MacCaw。
●What:
+ 用JavaScript實現MVC，MIT許可證。
+ 由最早為O’Reilly一本書寫的示例程式碼發展而來，已成為一個OSS（Open Source Software，開源軟體）專案。
+ 是Backbone的一個衍生版（看名字就知道3）。
●Why: 你喜歡Backbone，但又想要點不一樣的東西。
●When: v1.0.0已經發布。
3 Backbone和Spine都是“脊椎”的意思。——譯者注
Batman
●Who: Shopify （一家電子商務平臺公司）的團隊。
●What:
+ 在JavaScript中實現MVC，幾乎是專門為Rails+CoffeeScript開發者定製的，MIT許可。
+ 是所有框架中強制性規定最多的。你必須遵守其約定（例如，怎麼組織檔案和URL）。否則，就像他們幻燈片中說的，“你還是用其他框架吧”。
+ 非常完善的框架，具有相當豐富的模型、檢視和控制器，還有路由。當然，還有可觀察機制。
+ 基於DOM的模板。
●Why: 如果你使用Rails和CoffeeScript，你找到親人了。
●When: 當前版本 0.9，幾個月內將釋出1.0版。
CanJS
●Who: Bitovi（一家JavaScript諮詢/培訓公司）的團隊。
●What:
+ 用JavaScript實現MVC，MIT許可。
+ REST可持久模型、基本的路由、基於字串的模板。
+ 知名度不高（我也是上週才聽說它的），但它的前身卻是原來的JavaScriptMVC專案。
●Why: 旨在集上述各技術門派之所長，提供與它們類似的功能，同時又保持體積小巧。
●When: 1.0 版已經發布了。
總結
如果你正在考慮選型的問題，想知道上面這些框架/庫中的哪一個最適合你的新專案，那我建議你重點關注以下兩點。
功能範圍。你想讓這個框架或庫為你做多少事兒？你的專案是從頭做起，因而需要一個能貫穿始終的完整的各項功能齊備的架構嗎？或者，你其實更喜歡自己來挑選模式和庫？對不同的專案，不同的團隊，任何選擇都有價值，都是正確的。
設計美學。你看過它們的程式碼嗎，用沒用過自己選擇的框架構建出了一些小巧的應用？你喜歡這樣做嗎？不要只看它們的說明或者功能列表就作出選擇：那些資訊有價值，但不全面。打個比方，如果你置自己主觀的編碼經驗於不顧，那就像在選擇小說時只看它有幾章幾節，或者在找物件時只看其簡歷或個人描述。
儘管存在分歧，但我認為所有技術門派有一個重大的共性：它們都踐行了模型與檢視分離的思想。而這個思想早在Web誕生之前就已存在，到現在差不多有20年曆史了。這麼說吧，就算你只做一個基本的Web應用的UI，在客戶端應用這一思想也永遠是正確的。