摘要：從angular的誕生獨步天下，到現在三大框架平分天下，基本形勢已經趨於穩定。每一個框架從誕生到受歡迎，都有其特定的原因和背景。不同的開發者選擇時，也是依據於其特定情景下的原因和背景

一、為什麼前端會被vue,angular,react瓜分？

不知道大家有沒有發現，這三個框架除了都是前端框架之外，還大有搞基的成分存在。注意他們三個的名字，分別以v，a，r 開頭，我這麼一說，你是不是忽然間就想到了什麼。哈哈，正是如此，將他們組合起來不就是javascript中無處不在的鬼東西麼？var(當然純屬於開玩笑的)

在這裡我還是要推薦下我自己建的web前端開發學習群：617327703，群裡都是學web前端開發的，如果你正在學習前端 ，小編歡迎你加入，今天分享的這個案例已經上傳到群檔案，大家都是軟體開發黨，不定期分享乾貨（只有前端軟體開發相關的），包括我自己整理的一份2018最新的前端進階資料和高階開發教程，歡迎進階中和進想深入前端的小夥伴。

var關鍵字，是js的變數宣告關鍵字，可以說，它是js得以執行的核心關鍵字，因為要想一段程式碼執行，首先得有各種變數和邏輯判斷做支撐，而在es6之前，js能宣告變數的，就它一個。這似乎也是暗示了vue，angularjs，react這三個框架的不可替代性啊，也不知道當時這三個框架的作者起名時的想表達的特殊含義是什麼，但偏偏就剛好對上了。當然，反過來說，也有可能是起var關鍵字的這個人，當時考慮得面面俱到。雖然看上去是巧合，但我總感覺這之中總有一種道不明的關係。雖然vue是後起之秀，但就目前的受歡迎程度來說，好像就是這個順序，至少國內現在肯定是這樣的。

有了這三個框架之後，我們告別了以前jquery麵條式的程式碼，也擺脫了到處操作dom元素帶來的繁瑣，模組業務劃分更清晰。這三個框架的出現，不僅讓前端的工作得以高效，也讓後端省了不少事，比如，路由控制。在以前，幹後端是對決要比前端高一個檔次的，但現在，完全不一樣了。如果有一個牛逼的前端，後端差不多隻需要會增刪改查的基本業務就能完全搞定一個web應用。當然，這裡只是針對程式碼部分，搭建伺服器之類的另當別論。

二、三大框架的優缺點

我們主要從資料流、檢視渲染、效能與優化、模組化元件化等四個方面來作比較

1、資料流

Angular 使用雙向繫結即：介面的操作能實時反映到資料，資料的變更能實時展現到介面。

1.1、它的實現原理：

$scope變數中使用髒值檢查來實現。像ember.js是基於setter，getter的觀測機制，

$scope.$watch函式，監視一個變數的變化。函式有三引數，”要觀察什麼”，”在變化時要發生什麼”,以及你要監視的是一個變數還是一個物件。

使用ng-model時，你可以使用雙向資料繫結。

使用$scope.$watch（檢視到模型）以及$scope.$apply（模型到檢視），還有$scope.$digest

呼叫$scope.$watch時只為它傳遞了一個引數，無論作用域中的什麼東西發生了變化，這個函式都會被呼叫。在ng-model中，這個函式被用來檢查模型和檢視有沒有同步，如果沒有同步，它將會使用新值來更新模型資料。

1.2、雙向繫結的三個重要方法：

$scope.$apply()

$scope.$digest()

$scope.$watch()

在angularjs雙向繫結中，有2個很重要的概念叫做dirty check，digest loop，dirty check（髒檢測）是用來檢查繫結的scope中的物件的狀態的，例如，在js裡建立了一個物件，並且把這個物件繫結在scope下，這樣這個物件就處於digest loop中，loop通過遍歷這些物件來發現他們是否改變，如果改變就會呼叫相應的處理方法來實現雙向繫結

Vue 也支援雙向繫結，預設為單向繫結，資料從父元件單向傳給子元件。在大型應用中使用單向繫結讓資料流易於理解。

1.3、髒檢測的利弊

和ember.js等技術的getter/setter觀測機制相比（優）：

getter/setter當每次對DOM產生變更，它都要修改DOM樹的結構，效能影響大，Angular會把批量操作延時到一次更新，效能相對較好。

和Vue相比（劣）：

Vue.js 有更好的效能，並且非常非常容易優化，因為它不使用髒檢查。Angular，當 watcher 越來越多時會變得越來越慢，因為作用域內的每一次變化，所有 watcher 都要重新計算。並且，如果一些 watcher 觸發另一個更新，髒檢查迴圈（digest cycle）可能要執行多次。 Angular 使用者常常要使用深奧的技術，以解決髒檢查迴圈的問題。有時沒有簡單的辦法來優化有大量 watcher 的作用域。Vue.js 則根本沒有這個問題，因為它使用基於依賴追蹤的觀察系統並且非同步列隊更新，所有的資料變化都是獨立地觸發，除非它們之間有明確的依賴關係。唯一需要做的優化是在 v-for 上使用 track-by。

React-單向資料流

MVVM流的Angular和Vue，都是通過類似模板的語法，描述介面狀態與資料的繫結關係，然後通過內部轉換，把這個結構建立起來，當介面發生變化的時候，按照配置規則去更新相應的資料，然後，再根據配置好的規則去，從資料更新介面狀態。

React推崇的是函數語言程式設計和單向資料流：給定原始介面（或資料），施加一個變化，就能推匯出另外一個狀態（介面或者資料的更新）。

React和Vue都可以配合Redux來管理狀態資料。

2、檢視渲染

Angular1

AngularJS的工作原理是:HTML模板將會被瀏覽器解析到DOM中, DOM結構成為AngularJS編譯器的輸入。AngularJS將會遍歷DOM模板, 來生成相應的NG指令,所有的指令都負責針對view(即HTML中的ng-model)來設定資料繫結。因此, NG框架是在DOM載入完成之後, 才開始起作用的。

React

React 的渲染建立在 Virtual DOM 上——一種在記憶體中描述 DOM 樹狀態的資料結構。當狀態發生變化時，React 重新渲染 Virtual DOM，比較計算之後給真實 DOM 打補丁。

Virtual DOM：

提供了函式式的方法描述檢視，它不使用資料觀察機制，每次更新都會重新渲染整個應用，因此從定義上保證了檢視與資料的同步。它也開闢了 JavaScript 同構應用的可能性。

在超大量資料的首屏渲染速度上，React 有一定優勢，因為Vue 的渲染機制啟動時候要做的工作比較多，而且React 支援服務端渲染。React 的Virtual DOM 也需要優化。複雜的應用裡可以選擇 1. 手動新增shouldComponentUpdate 來避免不需要的 vdom re-render；2. Components 儘可能都用 pureRenderMixin，然後採用 Flux 結構 + Immutable.js。其實也不是那麼簡單的。相比之下，Vue由於採用依賴追蹤，預設就是優化狀態：動了多少資料，就觸發多少更新，不多也不少。React 和 Angular 2 都有服務端渲染和原生渲染的功能。Vue.js不使用 Virtual DOM 而是使用真實 DOM 作為模板，資料繫結到真實節點。Vue.js 的應用環境必須提供 DOM。Vue.js 有時效能會比 React 好，而且幾乎不用手工優化。

3、效能與優化

效能方面，這幾個主流框架都應該可以輕鬆應付大部分常見場景的效能需求，區別在於可優化性和優化對於開發體驗的影響。Vue 的話需要加好 track-by 。React 需要 shouldComponentUpdate 或者全面 Immutable，Angular 2 需要手動指定 change detection strategy。從整體趨勢上來說，瀏覽器和手機還會越變越快，框架本身的渲染效能在整個前端效能優化體系中，會漸漸淡化，更多的優化點還是在構建方式、快取、圖片載入、網路鏈路、HTTP/2 等方面

4、模組化與元件

Angular1 -> Angular2

Angular1使用依賴注入來解決模組之間的依賴問題，模組幾乎都依賴於注入容器以及其他相關功能。不是非同步載入的，根據依賴列出第一次載入所需的所有依賴。

可以配合類似於Require.js來實現非同步載入，懶載入（按需載入）則是藉助於 ocLazyLoad 方式的解決方案，但是理想情況下應該是本地框架會更易懂。

Angular2使用ES6的module來定義模組，也考慮了動態載入的需求。

Vue

Vue中指令和元件分得更清晰。指令只封裝 DOM 操作，而元件代表一個自給自足的獨立單元 —— 有自己的檢視和資料邏輯。在 Angular1 中兩者有不少相混的地方

React

一個 React 應用就是構建在 React 元件之上的。

元件有兩個核心概念：props,state。 一個元件就是通過這兩個屬性的值在 render 方法裡面生成這個元件對應的 HTML 結構。

傳統的 MVC 是將模板放在其他地方，比如 script 標籤或者模板檔案，再在 JS 中通過某種手段引用模板。按這種思路，想想多少次我們面對四處分散的模板片段不知所措？糾結模板引擎，糾結模板存放位置，糾結如何引用模板。

React 認為元件才是王道，而元件是和模板緊密關聯的，元件模板和元件邏輯分離讓問題複雜化了。所以就有了 JSX 這種語法，就是為了把 HTML 模板直接嵌入到 JS 程式碼裡面，這樣就做到了模板和元件關聯，但是 JS 不支援這種包含 HTML 的語法，所以需要通過工具將 JSX 編譯輸出成 JS 程式碼才能使用（可以進行跨平臺開發的依據，通過不同的直譯器解釋成不同平臺上執行的程式碼，由此可以有RN和React開發桌面客戶端）。

三、我們如何選？

年輕的程式設計師都是好奇的貓，玩過一個又一個的前端框架。從毛球上弄出一條條的線，玩啊玩，最後這一個個的框架在腦子裡攪漿糊。有太多的選擇，就是一件麻煩的事；沒有選擇時，就是一件更麻煩的事；有唯一的選擇時，事情就會變得超級簡單。

當一個程式設計師學了某個最新的框架之後，通常來說這個框架有著更多的優點，這個時候最容易出現的想法就是替換現有的框架，科室現有的框架並沒有什麼大的問題，並且評估不充分的時候，新的框架則會有更多的風險。

所以最後總結一下：技術選型沒有銀彈，沒有一個框架能夠解決所有的問題。這時，為了更好的考量不同的因素，你需要列出重要的象限，如開發效率，團隊喜好，開發週期等時機情況選擇哪個框架最合適你當前的團隊和專案。