JavaScript寶座：七大框架論劍

JavaScript寶座：七大框架論劍

一週前，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的話說：「現現在，你說‘單頁應用’，都跟說‘不用馬拉的車’差很少了」（意思是，早已經沒那麼新鮮了）2。

2 「不用馬拉的車」（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說：「咱們加入了不少魔法，但都是不錯的魔法，換句話說，它們徹底能夠分解爲常規的操做。」

替代譯法

@時蠅喜箭 咱們用了不少「法術」，但都是好的「法術」，意味着能夠分解成合理的基本組件。
@連城404 咱們的代碼技巧性比較高，但絕非旁門左道，都是些由常規的基本語義元素構成的東西。
@玉伯也叫射鵰 咱們實現了不少巧妙的整合，真的很是巧妙，這些整合均可以分解成普通操做。

分歧：基於字符串的模板與基於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的一個衍生版（看名字就知道3）。
• Why: 你喜歡Backbone，但又想要點不同的東西。
• Where: GitHub 和 自有站點
• When: v1.0.0已經發布。

3 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，在客戶端應用這一思想也永遠是正確的。

（完）

 

http://www.ituring.com.cn/article/8108