聊聊技術選型 - Angular2 vs Vue2

作者介紹：李暘，美團點評前端工程師，3 年 Web 前端開發經驗，現在是美團點評點餐團隊的一員。

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

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

技術

開發者

語言

為了避免前端元件缺乏一致的管理方式，重造輪子，解決多人在快速迭代中協作開發導致的程式碼逐漸混亂，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，為後來的技術棧做技術儲備。

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