為項目進行框架級別的技術選型，就類似為籃球隊量身定制戰術，選擇一個適合開發團隊的規模和團隊成員的技術棧和能力，針對業務和項目，能幫助團隊贏得更多的技術，是每個軟件項目能夠順利推進的先決條件，也是業務常青的有效的保障。這里，我們來聊聊為一個新的前端項目挑選一個合適的技術模型，對比在去年都發布了 release 版本的 Angular2 和 Vue2（以下如沒有特別指明，Angular 即為 Angular2，Vue 即為 Vue2），并不作魚和熊掌哪個更美味的選擇，而是站在技術本身，對應項目和開發人員的角度，幫助工程師在所處的業務場景下挑選最好的武器。

[[343845]]

技術

開發者

開發者/團隊2016 年 release，核心由 Google 開發，周圍有些生態環境組件由 Netflix，Babel 社區，微軟等相關開發者開發，參與人數比較多，Google 后期不維護這個項目的可能性比較小，但是不能排除部分框架內使用的第三方組件（如 zone.js ）后期缺乏維護的可能性2016 年 release，由尤雨溪主導開發，目前作者已經全職開發 Vue，但是也不能完全排除后期作者停止維護的可能性，目前 issue 少，報告的 bug 都修復了業內使用情況國內推廣情況目前不明朗，國外比國內強，資料也比國內多國內推廣情況比較好，滴滴，阿里等很多團隊都在用，國外推廣情況也不錯文檔和資料提供中文文檔（翻譯質量一般），YouTube 資料很多提供中文文檔，資料相對 Angular 少一些

目前沒法確切的評估未來一段時間這兩個框架的維護情況，但基本能確定的是，框架的生命周期不會比我們大部分業務的生命周期短。Angular 的缺點在于，除了核心之外，像 core-js，rxjs，zone.js 等生產環境依賴的系統不是 Google 的人主導的，存在潛在質量問題的可能性，并且 Angular 目前已經發布了 Angular4 的 rc 版本（主版本跳過了 Angular3 ），后面預計半年進行一次主版本的更新，雖然相關開發人員承諾盡可能向下兼容，但是后續對主版本的頻繁升級對項目的影響還是個未知數；Vue 由于作者是中國人，在國內推廣的很好，口碑很不錯，作者也清理 GitHub issue 的速度也非常快，坑會相對更少一些，后面也和阿里合作成為了 Weex 的官方框架，而 Angular 在國內目前形勢還不是很清晰，主要原因可能在于中文資料的數量遠遠小于英文資料。從國內的使用情況以及社區發展來看，Vue 更勝一籌。

語言

官方使用語言

Typescript，官方提供 compiler-cli 把框架代碼從 Typescript 直接編譯到 Javascript 的 AST 語法樹，屬于對 Typescript 的深度支持

ES6+語言的開發者微軟(主導開發 Typescript 的是 Anders Hejlsberg，此人也是 C# 語言的項目負責人 )ECMAScript 標準委員會制定標準，各個瀏覽器廠商實現語言特點靜態類型，提供靜態檢查，現有 ES6+ 的超集，官方提供的編譯器能夠支持編譯到 ES5，ES6，貼合工程化的需要，適合團隊使用，學習成本不高動態類型，比較靈活，目前標準委員會每年更新一次標準，加入新特性，通常使用Babel 以及插件編譯到 ES5IDE/編輯器支持情況主流 IDE/編輯器支持，官方推薦 VS Code主流 IDE/編輯器都支持，語言新特性 IDE 相對文本編輯器支持的更好能否使用其他開發語言也支持 Javascript 和 Dart，并且官方提供這兩種語言的文檔也支持Typescript，但文檔相對較少

為了避免前端組件缺乏一致的管理方式，重造輪子，解決多人在快速迭代中協作開發導致的代碼逐漸混亂，Javascript 的動態類型增加了重構難度的情況，我們希望引入靜態語言，通過類型檢查使數據更清晰，通過接口規范開發行為，這一點 Angular 通過默認引入 Typescript 比 Vue 做的更好。Typescript 雖然本身是微軟公司的產品，但是從編譯器效率到使用體驗均比目前的 Javascript 要強，在編寫 ES6+ 代碼時，經常因為 Babel 插件質量問題導致的坑，能避免很多。

工具

ng-cli 提供了包括從開發階段架設前端 server 服務，代碼生成，查閱文檔，測試，到部署過程的構建等的一系列指令，相比 vue-cli 只提供基礎的項目初始化和構建功能，ng-cli 更好用。在 debug 工具層面，Vue 做的更好，vue-devtools 整合了 Vue 的狀態管理工具 vuex，而使用 Angular 的狀態管理方案 ngrx 的時候，則需要配合 Redux DevTools Extension。

除了 ng-cli，angular2-webpack-starter 也提供了完整的 Angular + Webpack 的種子項目。我們也可以根據業務調整具體的構建過程。

設計

從設計上看，Angular 提供了難以撼動的全面的解決方案，基本照顧到了開發流程的每個節點，他的 Form 支持，DI，測試流程，都是在開發體驗上優于 Vue 的點，但是為了追求全面性，Angular 就無法避免的存在構建后體積大小和整個框架侵入性太強的問題。而 Vue 作為漸進增強的框架，不在一開始就在使用場景和模式上限制用戶，而是通過官方提供的擴展，以及第三方擴展，逐漸為更復雜的需求場景提供解決方案，也給用戶提供了選擇的余地。

性能

我們截取 Vue 官方文檔上關于兩個框架性能的對比報告截圖。對比了 Angular 在去年 8 月發布的 rc 版本和同期 Vue beta 版本的不同操作的性能。可以看出，兩個框架都非常的快，Angural 和 Vue 在大多操作上性能指標均處同一個數量級，Vue 在部分指標上略勝一籌。

在內存占用上，Vue 要優于 Angular，但是 Angular 框架本身提供了非常多的特性，而 Vue 在開發過程中引入 vue-router，vuex，vue-class-component 逐步發展為 Vue 全家桶的過程中，會逐步增長對內存的需求。

開發模式

從學習曲線上看，Angular 要更陡峭，Vue 要相對平緩一些。在Web Componnet，PWA 上，Angular 要比 Vue 走的更遠，更適合未來的標準，面向 Google 自己的技術棧。從能夠開發的應用的全面性上，Angular 和 Vue 相差無幾。

彈性

在業務開發中，技術選型并不能僅僅滿足當前的業務需求的需要，而要考慮當前業務的狀態，是剛剛開始，持續發展，還是穩定維護。考慮到業務后期可能出現的增長情況，這就要求我們選擇的技術具備一定的彈性，能夠隨著業務伸縮，避免后期維護成本過高，擴展困難的情況的發生。

• 這里截取了前端框架選型遷移的統計情況。y 軸代表遷移之前的選型，x 軸代表遷移之后的選型。表格中顏色越深，代表從選型 A 到選型 B 進行遷移的案例越多。可以發現，大家最多選型遷移的目標是 React，選擇遷移到 Angular 的案例要比選擇遷移到 Vue 的案例多，選擇遷移到 Vue 的，絕大多數是 React 用戶（相反從 Vue 遷移到 React 的用戶也有一定數量）；而從 Angular 或 Vue 遷移到其他框架的案例較少，側面證明了這兩個框架在目前業界具備足夠的彈性

業務場景

這里我們以點評點餐的內部數據系統為例。我們把系統對不同前端使用場景的頻率和要求從0到10進行打分，分值越高的，相應場景的需求要求就越高，反之就越低。我們發現，我們的需求集中在圖表繪制，組件管理和表單的提交校驗上。數量較多的組件對于我們的組件管理方式提出了較高的要求；在已有的系統中我們對 highcharts 和 echarts 都有依賴，但是將逐步把圖表組件遷移到 echarts 上。對于echarts，目前有vue-echarts，對于highcharts，有人做了angular2-highcharts。

開發人員

目前點餐數據系統日常人力 1 人，對多人協作開發要求比較低，開發效率要求比較高，單個項目規模不大，有多端多項目開發的要求，技術選型能夠適應快速迭代是一個目標，最大程度上的減少人力瓶頸的出現。

結論

首先，技術上對比 Angular 和 Vue，都是值得長線投資的技術。Angular 提供大一統式的解決方案，從瀏覽器端，服務端，客戶端都有涉及，這種大一統的方案，優點在于在幾乎任何場景，框架都提供了標準化的行為，而 Angular 通過一種侵入式較強的編程范式，規范了使用框架的所有開發者的開發行為，更工程化，更適合大型項目多人協作，同時，框架本身更擁抱標準，面向新特性，后面發展空間很大，而缺點是，這種大一統的方案，無法單獨由谷歌提供，谷歌除了開發 Angular 的核心模塊之外，在異步處理，狀態管理，周邊工具，使用了為數不少的第三方的庫或組件，這些庫和組件的行為是否會出現問題，和后續發展，很難預測，潛在增加了風險，這些第三方的庫和組件，也有降低應用性能的可能性。

Vue 的切入角度是，這個框架可以被不同程度的使用，可以單獨使用核心組件的部分，也可以加入狀態管理，也可以加入路由管理，從一部分使用 Vue 到全站使用 Vue 開發，提供了開發者更多的選項，也借鑒了不同的框架，并對其優點單獨為 Vue 進行了增強。這種精簡和靈巧，非常適合項目初期的快速迭代，性能上，也沒有很大缺陷，隨著項目發展，性能也不會成為明顯的問題。Vue 的潛在問題在于，由于提供了開發選項，在多人協作開發的情況下，不同開發者對于 Vue 使用程度和場景的處理可能會不一樣，而隨著項目增長，以“快”為特點的技術，在工程化和代碼的管理上可能會出現困難，而像 Angular 提供的 DI 等功能，Vue 實現類似的功能就需要程序員進行手動控制，帶來了潛在的代碼管理的問題，目前雖然業界有不少使用 Vue 的場景，但是大型線上在穩定發展期業務，幾乎是沒有的。使用 Vue 在項目規模變大后，怎么處理 Vue 在項目中的地位，怎么組織代碼，都是我們需要考慮的。

在我們的業務和人力層面，我們對數據平臺架構的規劃是多端多層的，架構層服務于應用層，應用層服務于用戶。對于用戶層，新開始的項目面臨邏輯經常調整的可能性，也就是說對于應用層，我們需要一個靈活，能夠適應快速迭代的框架，而應用層的多種設備多種環境，也要求我們對性能要有起碼的考慮，目前現有的組件和庫，也希望新的框架能夠做較好的兼容和提供現成的解決方案。這種情況下，Vue 是比較推薦的，后期隨著應用端發展，Vue 能夠確保沒有性能瓶頸，也給了我們后期引入更多 Vue 解決方案，形成 Vue 全家桶或者撤掉 Vue，用其他方案的空間。而對于架構層，它發展的速度未必有應用層快，它對業務的要求是穩定，能夠增量開發，盡量避免推倒重來影響應用層，同時，它性能的要求明顯沒有應用層高，這種情況，我們需要單獨區分一下，例如如果需要做應用層的通用配置系統，配置應用層的 UI 組件，那么顯然這個系統的組件框架要和應用層一致，而像自助查詢平臺或其他項目，我們可以使用 Angular，為后來的技術棧做技術儲備。