[譯]ANGULAR VS. EMBER VS. REACT 如何選擇前端框架

當下最熱的Web前端框架概覽

作為前端工程師，我們生在最好的時代。標題中提到的三大前端框架都即將或已經發布了重大更新。Ember 在不到2個月前發布了可以平滑升級的2.0。兩周前 React 發布了 0.14 ，在邁向1.0穩定版的路上邁出了關鍵的一步。在本周之內，一場名為AngularConnect的技術大會將在倫敦舉行，很有可能公布 Angular 2 的時間計劃。

是的，還有很多其他的前端框架。也還有很多曾經一度很火但是現在已經不那么流行了的庫，比如 Backbone 和 Knockout。當然也還有更新更有趣的后起之秀，比如Aurelia。但是如果讓你現在做決定選哪個框架來做web app的話，Angular， Ember 或 React 是比較安全的選擇，因為他們背后都有長期有效的技術支持和活躍的開發者社區支持。那么哪一個才是最適合你的呢？讓我們一起來看一看他們各自的最新版本都帶 來了些什么更好的新特性。

?

ANGULAR 2.0 (一個激動人心的新版本)

Angular 是當下最流行的前端框架不是沒有道理的。它是最早發布的一個革命性的前端MVC框架。Angular 也給大家帶來了很多實用的功能。

但是所有這些都被 Angular 2.0 打破了。這是一個小小的敗筆。和 Ember 的更新方式不同，第二版的 Angular 幾乎完全重構了。這意味著：幾乎每一行代碼都發生了巨大的變化。這讓繼續重用1.0系列的代碼變得幾乎不可能了。所以要想直接平滑升級到 Angular 2.0 是根本不現實的。

然后軟件開發界的一大奇跡誕生了。Angular 團隊發明了一種 在一個項目中同時運行 Angular 1.X 和 2.0 代碼 的方法。采用這種方法你可以漸近升級。但是在我看來這種方式最關鍵的作用是解決了 Angular 幾乎已成定局的停滯不前問題和成千上萬歷史遺留代碼的維護問題。

既然解決了這個難題，那么時下的大多數 Angular 項目可以繼續使用 1.X 版本，并可以在 2.0 正式發布之后逐步升級。如果你并不著急在今年之內發布正式版本并且愿意承擔新版本的風險的話，那么直接從新版本的框架開始吧。做好API隨時會變的心理準 備吧，你的項目越復雜就需要越多的時間來修改你的代碼以保證在新版本下正常運行。

ANGULAR 2.0帶來了什么讓人期待的新特征？

很多，這個框架正在經歷自誕生以來最大規模的重構。

開發2.0的主要目的是消除不必要的復雜。他們刪除或者替換掉了大家熟悉的 directives, controllers, modules, scopes 等幾乎所有 1.X 時代的概念。取而代之的是一個最大程度使用 ES2015 和 ES2016 新特性并采用了不同的架構設計理念的框架，以期變得易于學習，降低上手難度。

除了讓框架變得簡單，2.0還有幾個值得注意的目標：

• 性能優化
• 支持原生應用開發
• 服務器端渲染

這些新特性對 Angular 來說意味著非常大的改動，并且是1.X版本一直一來所面臨的挑戰。讓我們進一步詳細談談這三個新特性以及這些改動意味著什么。

性能優化

性能優化是所有使用 Angular 的開發者最期待的新特性之一了吧。如果你使用 Angular 做了足夠久的開發，那么你一定會被性能問題所困擾。雖然終究是有辦法解決這些性能問題的，但是這個框架的坑實在是太多了。

Angular 的性能是被它的狀態查詢機制拖慢的。每次 digest 循環，框架都會檢查整個 APP 里面的成百上千個變量是否改變。它的新數據模型采用了和React一樣的機制：不可變的數據結構配合單向數據綁定。基于這一關鍵性的改變，Angular 現在只在數據變化時更新一次。從之前的監聽數據變成了只快速檢查數據對象的索引而不是值。

原生應用支持

使用 Angular 開發原生應用是2.0路線圖上的一個重大計劃。Angular 開發團隊曾和 React 團隊碰面并討論了如何實現這一特性。看起來他們打算借助 React Native 的底層技術實現2.0的原生應用支持。這必將引領一個新的時代，一個 hybrid app 擁有原生應用性能但跨終端共享一套邏輯代碼的時代。

服務器端渲染

另一個長期被期待的特性是服務器端渲染的能力。服務器端渲染可以縮短首屏呈現時間并解決客戶端動態渲染無法被爬蟲抓取從而影響SEO的問題。頁面渲染的加快將會明顯地提升下一代基于 Angular 開發的 web app 的用戶體驗。

誰應該選擇 ANGULAR？

Angular 很有可能在相當長的時間里保持前端框架里最流行的地位。所以選擇 Angular 開發新項目是一個比較保險的方案。2.0 相比第一版意味著一次翻天覆地的革命。事實上，這種革命就像 Ember 之于 SproutCore一樣（有趣的是，Ember 原本應該叫做 SproutCore 2.0）。

Angular 2.0 是用 TypeScript 寫的，這是一種源自微軟的新語言，相比原生的 JavaScript 而言增加了類型檢查和一些其他的增強特性。事實上， 在最近一次開發社區投票調查中 ，得票最多的是 TypeScript 。基于此，加上種種該框架的其他特性表明 Angular 的定位依然是大型企業應用。雖然現在就使用2.0版本還有一定的風險，但是相信2.0的正式版本很快就會發布了。

?

EMBER 2.0 (悄悄來到我們身邊)

Ember 對自己的定位是做酷炫項目的框架。也確實有挺多酷炫的應用是用 Ember 做的，比如 Apple 的iCloud 網頁版本， Discourse（由 Jeff Atwood 開源的一個新型論壇程序），還有 Ghost （新一代的開源博客程序）。Ember是由兩位業界大神 Yehuda Katz 和 Tom Dale 開發維護的。雖然不像其他兩個著名的框架一樣有大型互聯網公司在背后撐腰。但是它擁有一個活躍且牛逼的開發者社區。

在1.0的時候，Ember也因為隨意改動API引起了很多不滿。隨后，為了維持大家對開發團隊的信任，他們已經學會了如何在幾乎不改變用戶 API的情況下做底層的的大規模更新。他們用這種方法在今年初的時候發布了一個名為 Glimmer 的高性能渲染引擎。在2.0里面他們才移除了不支持這個新引擎的部分代碼和API。所以使用 Ember 2.X 開發的應用在性能上必將帶來一個質的飛躍。

EMBER 2.X 帶來了什么新特征？

• 支持 ES2015 帶來的新特性，比如 modules, classes 和 decorators
• 拋棄了 Mustache 模板引擎并 不再 支持尖括號格式的自定義組件引用
• 使用一種名為 pods 的以功能為單位的新方式組織模塊兒，取代了之前以文件用途區分的組織方式，現在一個組件就是一個 pods
• Controllers 將被 routable components 取代
• 利用服務器端渲染縮短首屏加載時間并增強對SEO的支持

誰應該選擇 EMBER？

Ember 為開發 web app 帶來了一個很棒的方案。就像上面提到的一樣，有很多酷炫的應用是使用這個框架開發而成的。它贏得了 Ruby 開發者社區的青睞，包括我們 Smashing Boxes 自己的 Ruby 開發團隊。如果你是 Ruby 開發者，Ember將會是很好的選擇。有成千上萬的文檔介紹了如何融合這兩周技術進行開發。想知道如何將 Ember Cli 和 Rails 集成到一起？沒問題， 這里有一個專題連載告訴你怎么做 。

Ember 同時也是那些喜歡一站式開發框架的人的最好選擇。我們往往浪費了大量的時間去探索、研究，嘗試整合那些并那么適合互相搭配的庫。Ember 幫你做了大量的決策，這些決策幫你節省了寶貴的時間。這兩種方案各有利弊，然而那些崇尚“夠用就好”的人會喜歡Ember的。

??

REACT 1.0 (應該和0.14大同小異)

React 是3個當中最輕量級的。事實上，它都不能算是框架。它其實只干一件事：渲染UI組件。甚至有人拿它和前面兩個搭配。當然了，更普遍的用法是搭配一種名為 FLux 的架構方案。 Flux 有別于傳統的 Model-View-Controller。像 React 生態系統里面的其他部分一樣，這僅僅是一個功能單一的庫。它負責將視圖層的變化傳輸到數據層。它并不包括其他框架常見的與服務器端通信、數據校驗或者注入 依賴等。當然了，如果你需要的話，你會找到其他庫來解決這些問題的。

非死book 創造 React 是為了解決他們自己希望在不同頁面中保持UI一致性的問題。剛發布的時候就因為它出色的性能和服務器端渲染能力引起了軒然大波。而這兩個特征正是其他同類 競爭對手一直在努力但尚未實現的。讓人欣慰的是 Angular 和 Ember 正在新版本中迎頭趕上。

React 所帶來的革命遠不僅僅如此。最著名的要數 React Native。非死book 在保留一套跨終端邏輯代碼的同時獲得了原生應用的性能。上月初， 他們開源了安卓版的 React Native ，給原生應用的開發增加了一種靠譜的選擇。

REACT 1.0 的主要目標是什么?

• 官網改版
• 改善文檔
• 增強對動畫的處理

所有的這些都圍繞著更好的開發者體驗。目前最大的功能缺失是一種輕松地創建動畫的方式。既然計劃中的改動如此之少，想必1.0很快就將要正式發布了吧。

誰應該選擇React？

React 無論對新項目還是老項目來說都同樣是很好的選擇。你可以很容易地把UI層的某部分抽出來用React重構。這對于漸進式地改造老項目來說是個好辦法。在 Smashing Boxes ，我們的很多前端工程師都越來越喜歡這個庫了。React 和 Flux 的組合也讓開發 web app 項目中最復雜的部分變得容易了。

React 在過去的兩年里引領了客戶端MVC發展的進程。其他的框架都在努力模仿很多React已經實現了的東西。技術社區的喜新厭舊也由此可見一斑。大多數的 React 項目都是用 ES2015 寫的，盡管瀏覽器并未完全支持 ES2015。如果你是最新潮技術的追逐者并且喜歡輕量的庫勝過框架的話， React會是你的菜。

實例對比

已經有人分別用這幾個框架開發了功能和界面都一樣的 TodoMVC app ，我對此有幾點看法。首先，這些框架看起來越來越趨同。盡管他們各自都有自己獨特的特性，但是在很多好的方面都比較一致。單向數據綁定就是一個很好例子。同樣的，他們三個也都將實現以XML節點為基礎的組件。

在這三個框架當中，Ember是上手最快的一個。只要一啟動，你馬上就擁有了一個具備自動更新功能的本地服務器和相關的最佳實踐引導。而對于其他 兩個來說，你還得花時間自己去配置 WebPack 或 Gulp 來讓你的項目跑起來。你需要關心項目的文件結構是如何組織的。或者你需要花時間去找一個初始模板。基于約定大于配置的原則，Ember把這些都幫你做了。

是的，于我而言，在這三個框架中，Ember花了我最長的時間去學習。僅僅只是做這個一個小小的試驗項目，有一種殺雞焉用牛刀的感覺。所以 呢，Ember有它比較典型的應用場景，不符合這種應用場景的情況下用起來很別扭。這兩點對 Rails來說也是一樣的。 Ember 給我的感覺比較適合多人開發且周期較長的大型項目。

相比之下，另外兩個框架更符合我的預期。Angular 2.0 給了我一點小小的驚喜。因為和 Angular 1.X 完全不同了，但是當我找到了一些例子之后上手很快。

從最終的代碼量來看，Angular app 的代碼量最少。React次之。怎么說呢，我感覺在寫React的時候思路比較清晰，“是的，我應該把這部分邏輯抽象到它自己的組件里去”。雖然這樣增加 了代碼行數但是對未來的維護來說更輕松。在 Angular 和 Ember 里面很容易就會在模板里面寫太多邏輯代碼或者是給組件增加很多方法。

最終的生產代碼流量大概占100K，在本地測試服務器中加載需要300毫秒。這個 TodoMVC 實在太小了所以體現不出來三者的性能差異。盡管如此，我們來看看 DBMonster 針對3個框架做的評測 (在墻外) 。 這個 app 成了 Ember 的 Glimmer 引擎的見證。現在我們可以放心地說三者在壓力測試中都性能表現良好了。

誰是最后的贏家？

顯而易見：這三個框架為什么這么火主要是因為他們都有各自的強項。正因為如此，我建議你三個一起學，就像我們 Smashing Boxes 一樣。沒有絕對的贏家。不同的框架適用在不同的場景。即使不考慮其他原因，把這三個框架都學習一下也可以幫你寫出更好的代碼。

于我本人而言，我真心喜歡 React 及其相關的生態。 它的基礎概念很容易上手 。基于較少概念的開發很容易，并且哪怕項目變得復雜了也具有良好的擴展性。我沒辦法量化這一點，但是它的理念有助于讓我寫出正確、零bug的代碼。如果我現在要開始一個新項目的話，我會選擇React。

話雖如此，這三個框架的前途都是光明的。他們的下一代正式版本都將顯著提升性能并支持服務器端渲染。Angular 和 React 都將支持iOS和Android平臺的原生應用開發。我們可以借助這些框架做很多以前做不到的事了。已經熟悉了這些框架并希望在有趣工作中深入實踐？ 點這里加入我們

翻譯自 http://smashingboxes.com/ideas/choosing-a-front-end-framework-angular-ember-react