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),並不作魚和熊掌哪個更美味的選擇,而是站在技術本身,對應專案和開發人員的角度,幫助工程師在所處的業務場景下挑選最好的武器。
技術
開發者
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,並且官方提供這兩種語言的文件 |
為了避免前端元件缺乏一致的管理方式,重造輪子,解決多人在快速迭代中協作開發導致的程式碼逐漸混亂,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 作為漸進增強的框架,不在一開始就在使用場景和模式上限制使用者,而是通過官方提供的擴充套件,以及第三方擴充套件,逐漸為更復雜的需求場景提供解決方案,也給使用者提供了選擇的餘地。
Angular2 | Vue2 | |
---|---|---|
元件 |
元件是ng2應用的核心 ng2的元件支援了 Web Component 標準 每個元件有明確的生命週期 |
具備完善的元件系統 元件可以從 template 生成也可以用 render 渲染 元件有明確的生命週期 使用 virtual dom 渲染 效能很好 |
路由 | 使用官方的 @angular/router | |
非同步處理 | 官方支援 RxJS,通過流模型處理非同步 | 沒有官方的非同步處理方案,可以用Promise,也可以使用 RxJS |
事件繫結 | MVVM 模型,提供指令,指令相對 Angular1 做了效能優化 | MVVM 模型,提供指令 |
動畫 | 提供 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 |
彈性
在業務開發中,技術選型並不能僅僅滿足當前的業務需求的需要,而要考慮當前業務的狀態,是剛剛開始,持續發展,還是穩定維護。考慮到業務後期可能出現的增長情況,這就要求我們選擇的技術具備一定的彈性,能夠隨著業務伸縮,避免後期維護成本過高,擴充套件困難的情況的發生。
- 這裡截取了前端框架選型遷移的統計情況。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