Ember.js 和 Angular.js 的比較

本文編譯自 Tom Dale（Ember.js 的核心開發人員）在 Quora 對一個問題的回答，深刻對比了 Ember.js 和 Angular.js。

我是 Ember.js 的開發者之一，常常有人問我應該使用 Angular.js 仍是 Ember.js？我認爲在作出選擇以前，你要知道本身想構建什麼樣的應用。

這兩個框架表面上有一些類似之處：都使用綁定，都比其餘框架（例如 Backbone.js）更易於開發 Web 應用。

我首先介紹一下 Ember.js 項目的由來。從 2009 年開始，我一直在蘋果公司參與 SproutCore 的開發。這是一個相似於 Cocoa 的 JavaScript 開源框架，後來演變成了你如今看到的 iCloud。當時，個人周圍都是一些世界上最最棒的 Cocoa 開發者。

多年來在客戶端應用方面，彷佛沒有出現真正的新突破。自 80 年代開始，咱們一直遵循一種固定的模式——代碼運行在本地計算機上，從網絡上獲取數據，而後在本地處理，並顯示在屏幕上。而現在惟一有變化的是，代碼運行在瀏覽器的沙箱環境中，而後加載所需的「二進制」文件，用戶再也不須要把軟件安裝到本身的硬盤中。

在考慮這些問題時，我首先會想到：在咱們以前，人們已經作了什麼？我認爲很難去爭辯框架是否成功，以 Cocoa 爲例，不管在 Mac 仍是 iOS 上，Cocoa 均可以讓開發者輕鬆編寫受歡迎的應用。

咱們但願開發者可以建立能夠和原生應用競爭的 Web 應用。要作到這一點，首先開發者須要先進的工具和正確的概念，幫助他們溝通和協做。

在開發 Ember.js 的過程當中，咱們花了大量時間從一些原生應用的框架（例如 Cocoa）中引入一些概念，但後來咱們以爲這些概念帶來的困擾多於幫助，或者並不適合用來構建 Web 應用程序。所以，咱們開始轉向其餘流行的開源項目，好比 Ruby on Rails 和 Backbone.js，從中尋找靈感。

所以，Ember.js 最終變成了一個綜合的、強大的、符合現代 Web 特性的、輕量級的工具。

在我看來，與 Ember.js 相比，Angular.js 更像一個研究項目。這一點從兩者使用的術語中可見一斑：Ember.js 使用的是模型、視圖和控制器，而 Angular.js 讓你學習做用域、指令和模板嵌入。

我徹底支持這種研究項目，但願它們能變得更好。可是，要記住，應用是要放到生產環境的。

一些大公司已經在 Ember.js 上投入了時間和精力，好比新版 ZenDesk 已經使用 Ember.js 重寫（他們對 Backbone.js 失望後，決定改用 Ember.js），Square 的整個 Web 層面都是基於 Ember.js 實現的（由於他們想要一個漂亮的響應式 UI），Groupon 的移動版 Web 應用也是使用 Ember.js 開發的。此外，還有不少創業公司經過 Ember.js 得到了成功，並開始向 Ember.js 社區貢獻。

而我目前所看到使用 Angular.js 開發的大多數應用只是演示項目而已，或這是 Google 的內部項目。

我和 Yehuda（Ember.js 開發者之一）一直積極邀請真正的用戶參與 Ember.js 框架的設計和維護，這能夠確保咱們在 Ember.js 中添加的功能在實際開發中有用。

事實上，過去幾個月，大多數 Ember.js 的開發工做都是由社區的核心貢獻組完成的，他們來自不一樣的公司。若是我和 Yehuda 哪天有什麼事情，或者咱們的公司倒閉了，Ember.js 還能持續發展。這是一個真正的社區項目，而不是「Google」的項目。

回到技術細節。Angular.js 的官網上寫道「Angular.js是 HTML 的將來，其目的是構建 Web 應用。」閱讀 Angular.js 應用的代碼時能明確看出這一點——用戶界面由 HTML 標記定義，而且使用有語義意義的屬性（好比 data-ng-repeat）裝飾。

而 Ember.js 使用 Handlebars 描述 HTML，來展示應用的界面。從美觀角度上看，你能夠想一想本身更喜歡 Handlebars 的句法（例如 ``），仍是更喜歡 Angular.js 那樣經過額外的屬性註解 HTML 的作法。我我的認爲，HTML 屬性有點雜亂，難以閱讀。固然，你可使用其中任何一種方式。若是 Ember.js 不存在，而我又必須使用一個使用數據屬性的框架，那麼我會考慮 Angular.js。

拋開美觀不談，我相信，Ember.js 使用基於字符串的模板也爲咱們帶來了一些優點：

• 基於字符串的模板能夠在服務器上預編譯。這樣能夠減小啓動時間，也意味着渲染模板能夠像調用函數同樣簡單。
• Angular.js 須要在應用程序啓動時遍歷整個 DOM，應用越大，啓動速度越慢。
• 若是想在服務器上渲染應用（讓 Google 爬蟲索引，或讓首次加載的速度更快），Angular.js 須要啓動整個瀏覽器環境，例如 PhantomJS，對資源消耗很大。而 Handlebars 徹底就是 JavaScript 字符串，因此只須要 Node.js 或 Rhino 這樣的東西。
• 若是應用愈來愈大，能夠輕易分隔字符串模板，還可使用惰性加載。

此外，Handlebars 只容許綁定屬性，而 Angular.js 容許嵌入實時更新的任意表達式。不少人最初把這視爲 Ember.js 的缺陷，但事實上：

• Ember.js 有簡單的方法使用 JavaScript 建立可計算屬性，能夠包含任意表達式。
• 每次更新時，Angular.js 都必須從新計算這些表達式，這意味着須要在應用中綁定更多的元素，速度會變慢。
• 由於 Ember.js 只容許綁定屬性，咱們很容易利用 ECMAScript 6 的性能優點，如Object.observes。因爲 Angular.js 發明了帶有自定義解析器的 JavaScript 子集，因此很難優化代碼。

通常狀況下，Angular.js 依靠一種叫作「 髒檢查（dirty checking）」的機制來肯定對象是否已經更改。「髒檢查」的方式是，掃描每一個對象和綁定的全部屬性，比較當前值和以前已知的值。若是發生了變化，就要更新綁定。正如你能想到的那樣，代碼中對象越多，消耗就越高。

我認爲這很好地說明了 Ember.js 和 Angular.js 理念上的區別。Ember.js 和 Angular.js 都力求簡單和易用。而 Ember.js 使你沒必要擔憂代碼中是否有超過 2000 個綁定。若是你在編寫大型應用，那麼你已經解決了你所擔憂的最大的事情。對於中小型應用來講，Angular.js 一樣適用，由於這些應用不會觸及 Angular.js 的限制區。

在 Ember.js 中，咱們老是但願利用瀏覽器和語言中的新功能，以便使事情變得更容易。例如，一旦 ES6 的 代理對象可用，咱們不會再要求你使用 get() 和 set() 方法。

這就是爲何我認爲，若是想構建雄心勃勃的應用，應該選擇 Ember.js。

咱們從不拒絕從其餘框架中吸收知識，由於這些框架已經知道構建大型應用的最佳方式。

咱們已經有了一個夢幻般的社區，有一羣最聰明的 Web 開發人員，他們致力於解決現實中遇到的難題。

此外，在開發過程當中，咱們對於性能方面和如何利用語言新特性方面也考慮了好久。Ember.js 是我和 Yehuda 一塊兒開發的，他是 TC39 委員會（負責 JavaScript 下一個版本的制定）的成員，JavaScript 經驗豐富。

咱們已經發布了 1.0 版 API，所以你能夠開始學習了，不用擔憂之後會有重大變化。