JavaScript寶座：七大框架論劍

        英文原文：Rich JavaScript Applications – the Seven Frameworks    

        一周前，Throne of JS 大會在多倫多召開，這應該是我參加過的最有料也最不一樣的一次大會。大會官網如是說：

加載整個頁面，然后再“漸進增強”以添加動態行為，這種構建 Web 應用的方式已經不夠好了。要想讓應用加載快，反應靈敏，而且又引領潮流，必須徹底檢討你的開發手段。

        這次大會邀請了七大 JavaScript 框架/庫的創建人，他們濟濟一堂，面對面交流各自的技術理念。所謂七大框架/庫分別是：AngularJS、Backbone、Batman、CanJS、Ember、Meteor、Knockout、Spine。¹

        聲明：我在會上講 Knockout，因此我的觀點顯然不是中立的。在這篇文章中，我重點討論這些創建人的思路和技術理念，盡量不提我贊成或反對什么。

        ¹ 沒錯，是 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 好像進入了一種禪宗所謂的入定的狀態，對一切都能坦然接受。他就像一個大人，看著一群孩子在那里辯論。

• Where: GitHub 及 自有站點。
• When: 至今已誕生近兩年了。

        Meteor

• Who: Meteor 開發團隊（他們剛募集到 1120 萬美元投資，因此可以全職開發）。
• What:

        + 前瞻性極強的一個框架，想不出有誰那么激進過（也許 Derby 算一個）。

        + 將一個服務器端運行時環境（用 Node+Mongo 搭建）和一個客戶端運行時環境銜接起來，讓你的代碼在兩端都能運行，還包含數據庫。利用 WebSockets 實現所有客戶端和服務器之間的同步。

        + 在修改代碼時就“實時部署”——客戶端運行時可以即時更新而不丟失狀態。

        + 可以看看這個視頻，對它的認識就會更全面。

        + 跟會上與我有過交流的所有人一樣，我也衷心希望這個框架獲得成功——Web 開發就需要這種激進的改革才能真正進步。

• Why: 你實在覺得做常規 Web 開發太無聊了，想找點刺激。
• Where: GitHub 和 自有站點。
• When: 誕生時間不長；除了其核心團隊在用，不知道還有沒有其他站點實際在用 Meteor。不過，這個團隊真是在嚴肅地做著一件前無古人的事。

        Ember

• Who: Yehuda Katz （之前開發過 jQuery 和 Rails）、Ember 團隊和 Yehuda 的公司 Tilde。
• What:

        + 構建“超級 Web 應用”所需的一切，MIT 許可。

        + 功能最多，體積最大。

        + 融入了很多設計理念，涉及如何分解并對頁面進行層次控制，以及如何利用一個狀態機驅動的系統聯結各個層次。

        + 正在開發一個功能非常完善的數據訪問庫（Ember.Data）。

        + 要在運行時控制整個頁面，因此不適合開發大頁面上的“富應用區”。

        + 對文件、URL 等都有相當嚴格的一套約束，不過要是不喜歡，你可以重寫，只要你知道怎么做就 OK。

        + 設計靈感來自 Rails 和 Cocoa。

        + 工具：為 Rails 提供項目模板（但如果你手工編寫代碼，也可以使用其他服務器端平臺）。

• Why: 常見的問題應該有通用的解決方案——Ember 提供了所有通用解決方案。
• Where: GitHub 和 自有站點。
• When: 尚未發布1.0版，但也快了。然后，API 基本就能穩定下來。
• AngularJS
• Who: Google（他們內部在使用）。
• What:

        + 用 JavaScript 實現模型-視圖-其他，MIT 許可。

        + 基于 DOM 的模板，具備可觀察能力、聲明綁定機制，還有準 MVVM 式的代碼風格（他們自己說是 Model-View-Whatever）

        + 內置基本 URL 路由和數據持久化能力

        + 工具：附帶一個 Chrome 調試器插件，讓你在調試的時候能夠查看模型；還附帶一個 Jasmine 測試框架。

• Why:

        + 從概念上講，他們說這個框架相當于一個“填料層”，蓋在當前瀏覽器上，以實現未來的瀏覽器將可能原生具備的能力（即聲明綁定和可觀察能力）。因此，我們現在就應該著手這么來寫代碼了。

        + 對服務器架構或文件組織方式沒有影響。可以用在頁面的某一小部分中——不需要控制整個頁面。

• Where: GitHub 和 自有站點。
• When: 成品級框架，Google 已經搞出來有一段時間了。

        Knockout

• Who: Knockout 團隊和社區（核心團隊目前有三個人，包括我）。
• What:

        + 用 JavaScript 實現模型-視圖-視圖模型（MVVM，Model-View-ViewModel），MIT 許可。

        + 功能集中在富用戶界面元素：基于 DOM 的聲明綁定模板，可觀察的模型加自動依賴檢測。

        + 沒有限定 URL 路由或數據訪問——可組合任意第三方庫（例如，用 Sammy.js 做路由，用純 Ajax 實現存儲）。

        + 在降低使用門檻方面下了很大工夫，提供詳盡的文檔和交互式示例。

• Why:

        + 只做好一件事（UI），向后兼容到 IE6。

        + 對服務器架構或文件組織方式沒有影響。可以用在頁面的某一小部分中——不需要控制整個頁面。

• Where: GitHub 和 自有站點。
• When: 到現在已經正式發布近兩年了。

        Spine

• Who: Alex MacCaw。
• What:

        + 用 JavaScript 實現 MVC，MIT 許可證。

        + 由最早為O’Reilly 一本書寫的示例代碼發展而來，已成為一個 OSS（Open Source Software，開源軟件）項目。

        + 是 Backbone 的一個衍生版（看名字就知道³）。

• Why: 你喜歡 Backbone，但又想要點不一樣的東西。
• Where: GitHub 和 自有站點
• When: v1.0.0已經發布。

        ³ Backbone 和 Spine 都是“脊椎”的意思。——譯者注

        Batman

• Who: Shopify （一家電子商務平臺公司）的團隊。
• What:

        + 在 JavaScript 中實現 MVC，幾乎是專門為 Rails+CoffeeScript 開發者定制的，MIT 許可。

        + 是所有框架中強制性規定最多的。你必須遵守其約定（例如，怎么組織文件和 URL）。否則，就像他們幻燈片中說的，“你還是用其他框架吧”。

        + 非常完善的框架，具有相當豐富的模型、視圖和控制器，還有路由。當然，還有可觀察機制。

        + 基于 DOM 的模板。

• Why: 如果你使用 Rails 和 CoffeeScript，你找到親人了。
• Where: GitHub 和 自有站點。
• When: 當前版本 0.9，幾個月內將發布1.0版。

        CanJS

• Who: Bitovi（一家 JavaScript 咨詢/培訓公司）的團隊。
• What:

        + 用 JavaScript 實現 MVC，MIT 許可。

        + REST 可持久模型、基本的路由、基于字符串的模板。

        + 知名度不高（我也是上周才聽說它的），但它的前身卻是原來的 JavaScriptMVC 項目。

• Why: 旨在集上述各技術門派之所長，提供與它們類似的功能，同時又保持體積小巧。
• Where: GitHub 和 自有站點。
• When: 1.0 版已經發布了。

        總結

        如果你正在考慮選型的問題，想知道上面這些框架/庫中的哪一個最適合你的新項目，那我建議你重點關注以下兩點。

        功能范圍。你想讓這個框架或庫為你做多少事兒？你的項目是從頭做起，因而需要一個能貫穿始終的完整的各項功能齊備的架構嗎？或者，你其實更喜歡自己來挑選模式和庫？對不同的項目，不同的團隊，任何選擇都有價值，都是正確的。

        設計美學。你看過它們的代碼嗎，用沒用過自己選擇的框架構建出了一些小巧的應用？你喜歡這樣做嗎？不要只看 它們的說明或者功能列表就作出選擇：那些信息有價值，但不全面。打個比方，如果你置自己主觀的編碼經驗于不顧，那就像在選擇小說時只看它有幾章幾節，或者 在找對象時只看其簡歷或個人描述。

        盡管存在分歧，但我認為所有技術門派有一個重大的共性：它們都踐行了模型與視圖分離的思想。而這個思想早在 Web 誕生之前就已存在，到現在差不多有 20 年歷史了。這么說吧，就算你只做一個基本的 Web 應用的 UI，在客戶端應用這一思想也永遠是正確的。

        原文鏈接：Rich JavaScript Applications – the Seven Frameworks    

        作者：Steven Sanderson

        翻譯：@李松峰