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