[轉]聊聊技術選型 - Angular2 vs Vue2

轉載：https://juejin.im/post/58cab85b44d9040069f38f7a

"Come, and take choice of all my library, And so beguile thy sorrow." —— William Shakespeare, Titus Andronicus

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

技術

開發者

	Angular	Vue
開發者/團隊	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 更勝一籌。

語言

	Angular	Vue
官方使用語言	Typescript，官方提供 compiler-cli 把框架代碼從 Typescript 直接編譯到 Javascript 的 AST 語法樹，屬於對 Typescript 的深度支持	ES6+
語言的開發者	微軟(主導開發 Typescript 的是 Anders Hejlsberg，此人也是 C# 語言的項目負責人 )	ECMAScript 標準委員會制定標準，各個瀏覽器廠商實現
語言特色	靜態類型，提供靜態檢查，現有 ES6+ 的超集，官方提供的編譯器可以支持編譯到 ES5，ES6，貼合工程化的須要，適合團隊使用，學習成本不高	動態類型，比較靈活，目前標準委員會每一年更新一次標準，加入新特性，一般使用Babel 以及插件編譯到 ES5
IDE/編輯器支持狀況	主流 IDE/編輯器支持，官方推薦 VS Code	主流 IDE/編輯器都支持，語言新特性 IDE 相對文本編輯器支持的更好
可否使用其餘開發語言	也支持 Javascript 和 Dart，而且官方提供這兩種語言的文檔	也支持Typescript，但文檔相對較少

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

工具

	Angular	Vue
項目搭建工具	ng-cli	vue-cli
debug工具	Augruy	vue-devtools

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 做爲漸進加強的框架，不在一開始就在使用場景和模式上限制用戶，而是經過官方提供的擴展，以及第三方擴展，逐漸爲更復雜的需求場景提供解決方案，也給用戶提供了選擇的餘地。

	Angular2	Vue2
組件	組件是ng2應用的核心 ng2的組件支持了 Web Component 標準 每一個組件有明確的生命週期	具有完善的組件系統 組件能夠從 template 生成也能夠用 render 渲染 組件有明確的生命週期 使用 virtual dom 渲染 性能很好
路由	使用官方的 @angular/router	使用vue-router
異步處理	官方支持 RxJS，經過流模型處理異步	沒有官方的異步處理方案，能夠用Promise，也可使用 RxJS
事件綁定	MVVM 模型，提供指令，指令相對 Angular1 作了性能優化	MVVM 模型，提供指令
動畫	基於標準的Web動畫API(Web Animations API)I)構建，對不支持的瀏覽器提供polyfill	提供 v-animation 和 v-transition 等指令
狀態管理	ngrx	vuex
構建和部署	分 Just In Time（JIT）模式和 Ahead Of Time（AOT）模式，配合 tree shaking 能夠大幅度減小打包代碼的體積	配合wepack等打包工具構建和部署，在不引入過多周邊生態組件的狀況下要比 Angular 體積更小
安全	對不信任值進行編碼，避免了 XSS 攻擊 使用離線模版編譯器，防止模版注入 官方 http 庫可以防止 XSRF	沒有強制性組織 XSS 攻擊的機制，輸出 HTML 要注意配合 v-html 指令

性能

咱們截取 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 相差無幾。

	Angular2	Vue2
兼容性	瀏覽器支持	支持到 IE8 以上
Web Component	支持	不支持
PWA	支持	支持
SSR	支持	支持
Native App	Nativescript + Angular	Weex
Desktop App	angular-electron	electron-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。

	PC端	移動端	查詢平臺	配置系統
表單提交	7	5	6	6
UI交互和組件	9	8	7	9
異步操做	5	4	4	8
動畫	2	2	1	2
組件狀態管理的複雜度	4	3	1	7
瀏覽器支持要求	5	7	5	5
echarts	2	8	5	8
highcharts	8	0	0	0
性能	3	4	3	5

開發人員

目前點餐數據系統平常人力 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，爲後來的技術棧作技術儲備。

對於新項目，咱們技術選型可能未必選擇一種，能夠根據特色和業務都進行嘗試，使用一段時間後，反饋給整個團隊，這樣，對不一樣的框架，咱們後期都有技術儲備，能保證咱們手裏能打的牌較多，不至於由於需求變的被動。因此咱們在點餐數據產品中，Angular 和 Vue 都進行了嘗試，也將在後續文章中，分享兩個不一樣技術棧在平常開發細節上咱們的積累

做者：美團點評點餐 連接：https://juejin.im/post/58cab85b44d9040069f38f7a 來源：掘金 著做權歸做者全部。商業轉載請聯繫做者得到受權，非商業轉載請註明出處。