標籤：

Angular2與React，前端的未來志向何方？

01-14

Angular2明年估計就會出來了，對現在滿天的React的衝擊將會如何？未來，前端將走向何方？

去年年底，我回答過一個問題：

2014 年末有哪些比較火的 Web 開發技術？ - 徐飛的回答

轉眼間一年過去了，Angular 2發布了beta版，React如日中天，只有Polymer還是不溫不火。

這一年時間內，我也經常觀察前端界的各種趨勢，關注各種創新點，並且跟業內同行進行過一些探討，最終結論是：這三個框架，代表著前端框架目前的三條路線，仍然是並行發展的，只是在發展過程中互相吸收先進的思想。

哪三條路線呢：

  1. 以Angular，Vue，Aurelia，Avalon為代表的MVVM路線
  2. React以及相關周邊
  3. 以Polymer，NovaJS等為代表的Web Components路線

這三條路線本質上都是前端組件化框架/庫，所以，組件化理念是它們的立身之本，雖然大家的實現方式有所不同，但很多理念都是共通的。具體差別在哪裡呢？

在這裡需要先提及三個名詞：

MVVM，Virtual DOM，Web Components

我提這三個詞的意思，並不是說它們就對應於剛才三條路線，人們往往會有誤解：比如認為MVVM是Angular等框架的專利；除了React，別的框架也就不能有Virtual DOM了。

其實不然。

MVVM框架們之所以被冠以MVVM的名號，因為他們都是非常側重於分層的，三層分得一般非常清楚。比如說我們看Vue，它的一個組件中，包含很明顯的三層。

但是在React的實踐中，如果應用的規模增大，數據的組合複雜度高，很可能到最後也搞成了類似VM和M的分層，在這個回答的評論下：如何正確、客觀地評價 React？ - 鄧欣欣的回答

@墨磊 提到的：

另，最近一些項目中，在 Flux 或者 類 Flux 的 Store =&> View 這一步，

因為一些歷史原因，依然不得不走向了這樣的過程 ModelStore =&> ViewModelStore =&> View，同樣可以視為 MVVM 吧。

所以，MVVM並非MVVM框架們特有，當基於React或者其他框架的項目變大的時候，仍然有可能作為一種實踐被用起來。

再來看Virtual DOM，目前React是有這個東西的，但MVVM框架的底層一樣可以搞起來。好幾個框架的底層都部分使用了這種理念，比如大家的track by，都可以把數據和DOM之間的關係索引起來，當一個數組的元素交換了，它們可以藉助這些索引關係，不銷毀原有DOM樹，而是直接把數據交換了設置過去。

如果MVVM框架不是使用先生成DOM，再提取模板配置這種方式，而是直接解析模板生成AST，做這層更加容易，而且可以比較容易替換成其他渲染方式，比如在服務端，或者在移動端的Native代碼中渲染。

再看Web Components，主流的MVVM框架其實都在往這個方向靠攏，而React由於使用工程手段解決了Shadow DOM和Scoped CSS這樣的問題，所以對此並不太在意，而且由於它實現的特殊性，要兼容Web Components反而比較難。

D2的時候我曾經跟 @賀師俊在這些方面有過交流，他認為MVVM框架們很可能最終跟Polymer合流，整個前端框架領域被React和MVVM流派平分，鹿死誰手尚未可知。

我覺得，目前的應用場景是足夠大的，每個流派都是可以活得下去的，無所謂東風壓倒西風還是反過來，雙方都能生存下去。到最後，當形成整體解決方案的時候，很可能兩派方案都是殊途同歸：

  • 視圖層實現了Virtual DOM

  • 宏觀上組件化，形成組件樹

  • 微觀上MVVM，並且都應用類似Flux，Redux之類的數據層方案

  • 編程模型吸收Immutable和Rx的

  • 通信層應用Relay或者Meteor之類的方案

比較大的區別可能是對Web Components標準的應用程度，MVVM系可能都會使用它，並且相應地採用不同的CSS資源管理和構建方案。

去年年底的時候，有一件事情我沒有想到，那就是ES6的普及速度，有鑒於此，我認為，未來一兩年內，ES新版本會成為各路組件化開發方案的默認配置，並且得到廣大開發人員的接受，TypeScript也可能會隨之大放異彩。

另外有一點我沒有考慮到的就是HTTP2，這個經過 @賀師俊指出之後，我覺得很有道理。我總結一下他的觀點：之前我們都會考慮代碼的合併打包等方案，但是當HTTP2普及之後，這方面很可能不是問題，人們會回歸一種只專註於代碼本身，而不是著重考慮現有這些類型的優化方式，所以這可能會對各類工程管控優化方案有個顛覆。

目前能看到的大致這些，一年後來看看。

順便回答你的問題，1-2年內，Angular 2應該不太會顛覆得動React，甚至要超越自身的1.x版本都比較困難，更詳細的見這裡：如何評價 Angular 2 發布 Beta 版本？ - 徐飛的回答

倒是Vue，在2016年的增長會很令人期待。

干過幾年的前端，並且會在前端這條不歸路上繼續走下去。。。

從開始的ie6風行天下的時刻加入前端這個行業。眼睜睜看著這個行業的風起雲湧，最落寞不過是一個個項目由風光無限轉到寂寥到無人問津。

ie6-8+ firefox 3的時代，jquery+jquery 插件大行其道。那時候面試的時候問的最多一句，jquery的插件有幾種寫法，面向對象的插件與普通插件的異同。jquery的源碼有沒有讀過。你有沒有讀過jquery源碼？dom操作，api精簡，鏈，deferred，這些思想沉澱的深刻。

到大而全的框架開發，比如dojo，extjs，jquery UI，YUI是的，這些動輒幾十兆的開發包，掌握一個框架就可以吃一行飯。至今還記得半夜讀extjs的源碼時的一聲聲嘆息，原來js，前端代碼可以這麼寫。

到後來模塊化崛起，問的做多的是，seajs，requirejs，amd，cmd，umd，nginx的combo 的各種差異，而這些也是如數家珍一樣。

html5，webkit，跨終端，css3，sass，less 崛起，bootstrap風靡中國。

nodejs攜著npm攪起前後端分離，js服務端開發拉開序幕。

小而美，函數式，mirojs集錦，undersocre,q等等...一個個前仆後繼的在js中誕生。技術變得日新月異。

再後來ES5，ES6，ES7相繼出台，一方面彌補js在語法上的不足，一方面又像改革的春風吹向前端這個圈子。

angular2，reactjs，native，web components。。。

web工程化。gulp，grunt，fis。太多太多了。

其實這些年走來，看著這些技術有苦澀也有欣慰。這個行業的發展要比以往刀耕火種，沒日沒夜的切圖，圍著設計稿打轉，寫完html，css，寫jquery 動效，至少加了新鮮的熱辣的元素。

我也曾迷茫過，也曾彷徨過，也曾想著換個坑，換個職業，換個人生，看不一樣的風景，聽不一樣的故事。但最後還是留下來了。

做技術就是做人做事。迷茫的時候不如去看看這些人是怎麼想到這些技術，怎麼做出這些成就。看看源碼，看看設計。也就明白了很多道理。

angularjs 做個內部管理系統，是足夠的，也是健全的。比extjs好些。你用了，你就知道了，你不用，永遠在門裡面看門外的風景，其實也就只有一個門框的視野。機會只給勇於弄髒自己雙手的年輕人。

祝永遠年輕，永遠熱淚盈眶。

其實不妨找一下兩者的共同點，就大概能對「未來」有一個大概理解。

首先是component的概念在兩者中都有了實際的抽象，angular 2的@Component和React的createClass，大致的概念和抽象層次是一致的，只不過實現細節有很多不同罷了；這些框架做的，就像jQuery對DOM API做的那樣，在Web Component實現沒有最終一致成型之前，給開發者市場提供一種解決了兼容性的方案。Component的狀態是自維護的，架構複雜應用的思路會清晰不少。

其次是Declarative，declarative的語言設計好了，原型方便，介面直觀，復用定製間有比較好的平衡，容錯處理好等等，對設計人員和開發人員都是福利。你不需要寫比較複雜的JS來實現功能了，只需要寫HTML就可以。

這兩個概念並沒有讓開發做原來JS+CSS+HTML做不了的事，而是解決開發粒度的問題，讓前端有一個清晰的從高到低的設計與架構框架，高就是設計Component的拓撲，低就是每個Component的內部實現。

這兩個概念也並不新鮮，只不過在用jQuery Plugin做前端的時代，還沒有產生這種清晰的架構思路，主要關注形成功能，一個功能塊的模塊化完全模塊化必須依賴JS或者某種預編譯工具，有了Component和Declarative的概念，開發的思考起點跟清楚了，更重要的是，團隊開發的一致性應該會更好，依據Component的模塊化對測試與部署也是很有用的。

這不會因為使用angular 2還是React有很大不同。

兩個我個人都喜歡，都好用，不夠我可能更偏向angular 2一點，雖然不認為React會因此消失。碰到這樣的問題，我的一般回答都是「都看都學也無妨」，互為映襯能融合視角。

我沒什麼特別有說服力的理由，不夠直覺上angular 2的實現自然一點，Component templating是100%的HTML，相比React的JSX語法覺得沒有使用上的奇怪感覺，倒也不是有多難用。因為框架里有許多黑魔法，這樣我可以把注意力放在設計好Component本身身上，而不需要額外花精力關注如何使用這個Component，比如angular 2讓你關注需要render的template，而不是render的過程，這樣能更快地產生比較好的Component封裝。angular 2的移動native支持還弱一點，但按照google的實力，我想並不需要擔心在不久的將來它的移動native端應用能力會比react native弱多少，況且angular 2是可以和reactive native集成的。

總的來說，我覺得不太會是一邊倒的情況，angular 2是值得看的。

Angular、Vue、React 和前端的未來

其實個人感覺前端讓人很困惑，隨意吐幾個槽吧。

1.react 寫proptypes一度讓我覺得很煩惱，因為我的項目並不需要太多復用components，但是我看不得lint報錯。

2.類型系統的缺失也很煩惱，有時候期望一個強大的類型系統，有些問題確實是很trivial而且時不時跳出來感覺就是很煩。毫無疑問最好就是上typescript，但是我內心是想上scalajs的。

3.angular的作用範圍和react其實不太相同，angular寫著很快啊，寫crud簡直突出一個快。官方網站也是推薦寫crud（我記得是這樣的。

4.react flux寫起來真的很啰嗦，竟然都沒有人吐槽。唯一見@尤雨溪吐槽過redux，的確是很繁瑣。我如果mvc就搞個model，vc混寫寫小東西喝喝茶就寫完了。react的話，要寫action-&>action creator-&>reducer/dispatcher-&>react component，這只是一個交互操作，如果是非同步請求還要*3。（寫action常量不是我想要的生活。

5.react好處是需求變更，可以亂改坑不是很大。

6.react寫得煩躁的時候就會想偷懶，全局狀態啊，不在action裡面非同步啊，把別的插件包個react皮膚就上啊。重要的還是要有review啊。

7.所以我想吐槽的是，搬磚的時候重要的都是deadline。如果ddl需要，react配個eventEmitter寫起來最快了。

8.0.13到0.14有天刪了一下node_modules，然後重新安裝，好幾個包都不認識了。

====更新內容====

如何工程化開發大型angular2項目（上篇續）（分享自知乎網）https://zhuanlan.zhihu.com/p/24545021

如何工程化開發大型angular2項目（上篇）（分享自知乎網）http://zhuanlan.zhihu.com/p/23808621

===============

淺談一下從3月份到現在用angular2的體驗。alpha版到rc.7，之間變動之大。router系統重構好幾版，component組件編寫語法也是變了好幾次。上頭追新，作死應用到生產環境，應用越做越大，打包出來JS都快2、3M。導致客戶普遍抱怨首屏載入慢。還好後來在Nginx伺服器上做了優化，還有angular提供了預編譯技術，先渲染HTML。速度提升60%。

這裡也不是抱怨angular小組技術變動大，畢竟還是研發階段。我想提一點是，追求新技術是值得鼓勵的，但是不要把還在研發的技術應用在主線產品中，而是用在一些內部系統中。不然真是血的教訓。

當然要說說，angular這次變革式創新出了2代。優勢有

1.學習成本降低，因為有中文版文檔www. angular.cn,在也不用聽新同學抱怨英文看不懂。基本看幾天就能上手。會angular2,看vue基本無壓力，反過來也行得通。

2.技術實現成本降低，用angular1實現組件共用，用2輕鬆實現。現在項目里已經有很多通用組件了。

3.react，vue的redux，angular2也有，ngrx技術。

4.對於選擇恐懼症的盆友，angular2真是一站式服務。

5.聽說react可以開發native app，不好意思angular2和nativescript也可以開發原生app。 忘了說一句，angular2還可以開發react native。(自行上GitHub搜索angular2 react native).

6.最六的是支持Rx.JS。

7.人生苦短，快用angular2吧。

PS：哪有蘿蔔坑，準備挪坑，私聊

本人從事前端工作也有差不多10年，我一直認為這些框架都是工具，最討厭為了一種新技術放棄整體效果和用戶體驗，對前端來說最重要的還是創意和思想。框架這些東西好比食材，真正價值在於廚師的廚藝，即使用上個時代的bootstrap tweenmax也可以製作美好的桌面作品。有人說ng1有多垃圾，vue有多優雅，悠悠眾口眾說紛紜，我是懶得去聽，前端工程師常犯的錯，就是追求新潮，忽略了技術要為社會服務這個基本的常識，心態焦慮而急躁，生怕被時代拋棄，失去競爭力，或者抱著投機致富的心態。我常對同行說，不要炫技，老老實實寫代碼。前端的未來，不在投入哪個門派，不在採用哪個框架，而是你能不能真正解決問題，你的數萬個工具在一起是否和諧，你的代碼是否健壯這些基本的東西。

以社區志願者的心態，寫了angular2和react+redux的實例系列教程，目前為止，react+redux教程的star零頭都比angular2教程多

GitHub - lewis617/angular2-tutorial: angular2-tutorial in Chinese

GitHub - lewis617/react-redux-tutorial: react-redux-tutorial in Chinese ,catalogcode examples

吐槽一下：Redux框架實現伺服器端渲染是個餿主意，以下這個boilerplate沒人吐槽，不科學啊！

就是這個東東，react-redux-universal-hot-example，坑連坑啊，坑爹的貨！裡面有個核心模塊叫redux-async-connect，開發者已經放棄更新了，而且這個模塊沒有說明文檔！還有個更坑爹的模塊叫 redux-form，裡面的開發者文檔也是《九陰真經》風格的！react-redux-universal-hot-example 這個模塊我花了近半年時間才基本搞明白，結論是伺服器端基於Redux技術的渲染是個糟糕的注意，還不如直接寫PHP。我現在安心使用Anglar2了。

其實不管前端還是後端，，方向一致沒變，大而全的框架很難真正的一直流行下去。但是小而美的框架在流行之後又很容易走上大而全。。

後端有j2ee之於ejb-&>spring,hibernate-&>mybatis等等這些技術變遷！就跟現在後端流行的微服務一樣，設計精巧，可以比較好的與其他技術兼容。

不管你怎麼吐槽jquery,backbone這些類庫或者簡單框架，但是很明顯他們本身沒有很明顯問題,而且很容易和其他框架結合起來，，，我相信在一段時間之內至少jquery，還會存在併流行下去.

vue流行起來不也是小而美的原因，如果他一開始就做angular模仿著，我相信幾乎很難流行起來..

angular有他的市場，有他合適的場景，但很難說是前端的方向，，

react列，我很難評論，

前端一直以來不就是合久必分，分久必合.適合自己，適合團隊，打好基礎才是實在.

前端未來的方向是精通js

換個視角來看問題，如果問題主體是前端的未來，那與Angular關係不是特別大，與React關係大點。

建議大家認真想下，別只看字數長回答，大部分有想法有遠見的人沒那麼多時間來編輯巨長無比的答案！

fis和其生態也可以算一種吧

ng2 + rx.lite min之後700K+，大小是react + redux + ng1 + ember 的總和左右，你感受下

angular 和 react, 知識js發展的其中一個很小的階段而已，和後端語言一樣，指不定那天會有新的東西出來代替，作為開發著，保持擁抱學習的心裡，懂得Js基礎知識，不管啥框架出來，很快都可以消化，每個框架都有它存在的理由，沒有必要偏向於哪個框架，沒有好不好，是有適合不適合。

用了React簡潔的JSX syntax以後再也不想用Angular那個繁瑣的directive了。

話說JSX要是能跟TypeScript，Webpack結合起來就好了。

雖然現在也可以這麼做，但是Facebook推薦跟react一起用的是Flow，而不是typescript，還是觀望一下Flow的發展吧。

原生js是未來方向！

React vs Angular 2: 戰爭繼續

by ouven

2016年04月07日 in Article-translation

React vs Angular 2: 戰爭繼續

React vs Angular 2: 戰爭繼續

【原譯】：React vs Angular2: The fight rages on

google的Angular和Facebook的React是現在最流行（但不是只有兩個）的瀏覽器端應用開發工具，它們都是很優秀的解決方案。然而angular 2仍然在beta版中，Google的一部分工程師已經對它進行測試了。使用react開發的應用也很多，像instagram，netlfix，paypal等。

殘忍的戰爭就要到來了。

第一滴血

已經有一篇」血腥「的文章《Angular 2 versus React》（作者：Cory House）來比較angular2與react，它體現了兩者很多方面的亮點，第一次對決已經結束，但是大戰才剛剛開始。（譯者註：老外寫個文章真的一定要這麼誇張嗎？哈哈~）

認清你的對手

作為開發者，選擇angular還是react就像購買現成的電腦還是用現成的零件來組裝電腦一樣。

Cory House告訴我們：

angular 2React壓縮後764K壓縮後151k獨立的完整解決方案簡單的視圖庫很多angular特定的語法javascript語法很好的一致性（和typescript）基本語法有點混淆使用html和jsjsx語法綜合成熟穩定的框架發展迅速的開源庫手動debug，缺少完全的支持jsx-很好的開發體驗對web components友好有可能支持web componnets靜態執行jsx-動態執行

我想補充的是react有很多優秀的瀏覽器開發插件，然而並沒有看到angular 2的。

競技場

為了比較這些前端的技術，我做了一些TODO應用。為了使問題更加簡單，我在兩個應用中只使用了Redux core（受angular 2-introduction to Redux啟發）。兩個都是使用typescript開發的，所以比較起來比較清晰些。你可以對比下代碼：

– Redux Core: GitHub - evojam/redux-todo-lib: Redux – Angular2 App: GitHub - evojam/angular2-redux-sample-app: Angula2 Redux – React App: GitHub - evojam/react-redux-sample-app: ReactJS Redux

對抗

兩者的核心都是一個component或是一個view單元。兩個都將你的app形成一個組件樹。它們都鼓勵將數據通過頂層傳遞給組件樹。根到葉子的數據流思路使我們開發的應用」更靈活」，所以現在開始。

第一輪：功能組件

在這個樹形結構的基礎應用中，每個頂層樹是一個組件，每個組件的特點：

  • 從父節點接受數據（稱之為輸入）
  • 返回一個組件的子樹（視圖view）

在angular2和React中，輸入都是通過子節點屬性（不是html屬性）從一個元素傳遞到它的子樹，兩種解決方案中，視圖view都可以理解為xml樹。

TodoList組件

一個可復用、可選擇、簡單的todo list需要做到兩點–todos數組（我做的數組）和過濾的方式（要展示的數組）。所以我們的組件輸入可以是這樣的：

interface ITodoListProps {
todos: ITodo[];
filter: FilterType;
}

而組件在任何地方都可以這樣使用：

– React

&

–Angular 2

&

    &

    下面是React組件的定義：

    // src/components/todo-list.tsx

    import { Todo } from "./todo";

    export function TodoList(props: ITodoListProps): JSX.Element {
    return (
    &

      {todosFilter(props.todoList, props.filter)
      .map(todo =&> (
      &
      ))}
      & );
      }

      下面是Angulart2組件定義的版本：

      // src/components/todo-list.ts

      import { Todo } from "./todo";

      @Component({
      changeDetection: ChangeDetectionStrategy.OnPush,
      directives: [Todo],
      host: {"class":"todo-list"},
      pipes: [TodosFilter],
      selector: "[todoList]",
      templateUrl: "/src/components/todo-list.html"
      })
      export class TodoList implements ITodoListProps {
      @Input() todoList: ITodo[];
      @Input() filter: FilterType;
      }

      // src/components/todo-list.html

      &