'2019年過半，前端所有流行必學技能總結'

作者：前端你怎麼看

一晃眼2019年已過大半，年初信誓旦旦要學習新技能的小夥伴們立的flag都完成的怎樣了？2019年對於大前端技術領域而言變化不算太大，目前三大技術框架日趨成熟，短期內不大可能出現顛覆性的前端框架(內心OS：出了也學不動了)。

本文結合個人和團隊經歷對2019上半年做個技術總結，將各類技術框架/語言/工具分作兩個維度：

技術採用生命週期

• 創新者（Innovators）：技術的冒險者，第一時間嘗試新技術
• 早期採用者（Early Adopters）：技術早期採用者，具備一定探索精神，某個領域的意見領袖
• 早期大眾（early majority）：技術早期大眾使用者，深思熟慮者，往往採用相對成熟的技術
• 晚期大眾（late majority）：技術的平民老百姓，跟隨趨勢採用當前主流的技術
• 落後者（laggards）：技術的落後者，長時間不更新技術棧，存在大量技術債

技術方向

按照大前端技術架構圖進行分層，大體分為：狀態管理、UI組件、小程序、跨平臺、框架層、編程語言、工程化、監控、測試和服務端。

2019年大前端技術總結如下：

狀態管理

隨著React、Vue這類前端框架的流行，組件化開發成為主流，然而隨著頁面複雜度越來越高，在一個組件文件中，要做UI渲染、事件處理、狀態管理等等事情，於是一個文件變的越來越複雜。同時，頁面組件層級變的複雜後，跨組件間的數據通信也變的很繁瑣，需要將數據上提到父節點，通過property傳輸數據、回調方法更新父節點狀態等等。

Facebook首先提出Flux框架，引入單向數據流的編程模式，把Action和Store從View中解耦出去，極大的優化了原有狀態管理的架構。

Redux=Flux+Reducer，由於Store的唯一性加上Reducer純函數，使得數據狀態具有可預測性，於是配套出現了很多基於TimeMachine機制的調試工具，極大的提升了研發調試效率。不過由於Reducer的純函數性質，對於一些異步請求的副作用又要引入中間件，導致了一定的複雜度。

Vuex作為Vue框架的狀態管理的不二選擇，核心思想和Flux/Redux一脈相承，弱化了Reducer的概念而改用Mutations，使得整套框架更易於理解了。

Mobx是一個非常輕量級的狀態管理框架，引入了observable state、computed value，極大的簡化了狀態修改的方式，相對於Redux減少了不少模板代碼，上手迅速使用友好，不過由於缺乏Redux這類的強制規範，需要在使用中進行必要約束。

dva是螞蟻金服出品的數據狀態管理框架，dva=React+Redux+Saga，通過約定大大簡化了編程體驗，值得持續關注。

狀態管理不是每個前端應用都必須使用的，要結合自身業務複雜度來決定，只有業務邏輯有一定複雜度需要做到各個模塊解耦才考慮採用，如果一個Todo都用上Redux，我懷疑你是在炫技~

UI組件

在前端三大框架還未一統江湖的時候，組件庫百花爭鳴有Dojo、Bootstrap、Extjs等等。自從React橫空出世，組件化變成了前端開發的標準模式，同時也應運而生了兩大UI組件庫：基於React的Ant Design和基於Vue的ElementUI。

作為兩大成熟UI組件庫，如果你的系統是屬於中後臺業務，對於UI定製化要求不那麼嚴格，那麼這兩個一定是不二選擇，兩者功能上沒有太大區別，基礎UI控件、多語言、主題配置等等要啥有啥，唯一的風險就是聖誕節給你來個下雪的彩蛋（政府網站高危預警）。

UI組件庫可以持續關注Web Components，畢竟是Chrome瀏覽器親生的，背後有Google這個老爹撐腰，而且現在React/Vue不也變的越來越像Web Components了嗎？

另外前端數據可視化、3D化也是一個很好方向，一些酷炫的前端庫小夥伴們可以擼起來了~

小程序

2019年小程序百花齊放，各大超級App都推出了自己的小程序應用，前端同學們要支持眾多小程序，摸摸頭髮又稀疏了不少吧（em...離資深研發又邁出了堅實的一步）。小程序的實現有多種方式，需要結合自身的業務場景來做選擇。

選擇一，小程序原生開發方式，以微信為主開發小程序，再通過少量修改移植到其他平臺（工作量多少沒有做過不好估計，但既然當初支付寶小程序demo都抄微信的，感覺應該不大吧~）

選擇二，H5內嵌開發方式，天然多平臺跨端，但會有些許性能損失，也會有些功能限制，例如微信裡面的消息通知不能通過H5來推送

選擇三，mpvue這類基於某種框架的開發方式，mpvue就是基於vue框架來開發小程序，對於熟悉vue的同學學習曲線很低，同時也可以實現代碼邏輯的複用

選擇四，Taro跨多端的實現方式，支持用 React 的開發方式編寫一次代碼，生成能運行在微信/百度/支付寶/字節跳動/ QQ 小程序、快應用、H5、React Native 等的應用。對於功能需要同時滿足多個小程序應用的場景比較適合。

跨平臺

錦濤在Qcon分享 - 美團移動端動態化實踐中總結了業界和美團在移動端跨平臺&動態化的實踐，可以看到公司在跨平臺&動態化方面進行了多維度的研究和投入，這樣可以適用於不同的業務形態。

自從移動端有了iOS、Android兩大平臺，在加上原有的H5 Web端，跨平臺就成了這幾年大前端最熱鬧的地方，畢竟一個功能實現三套換誰都不樂意幹，於是在用戶體驗和研發體驗中的一場拉鋸戰就開始了，各大廠商各顯神通。

最早出現的是Phonegap這類基於WebView的實現方式，由於WebView天然跨平臺能力很好的解決了展示層的問題，然後通過jsBridge打通WebView和Native之間通信，使得瀏覽器中的H5代碼也能有原生能力。這種方式研發體驗最好，但是用戶體驗最差。

然後就是React Native、Weex、Picasso，它們基於Virtual Dom或者模板語言，通過js代碼編寫UI，然後渲染成原生組件，完美了實現了用戶體驗和研發體驗的平衡。但要用好這些框架還是需要對性能優化、差異性抹平、工程化有比較高的要求，小團隊小公司慎用，否則入坑容易出坑難。

今年大熱是Flutter，可以持續關注，技術架構很優秀，野心很龐大，大有一統江湖的氣勢。

跨平臺熱熱鬧鬧多年，我個人認為當前的解決方案都是折中方案，隨著手機性能逐步優化、瀏覽器原生能力的增強，也許大家都會迴歸本源，走上H5這條道路。

框架層

上半年框架層沒有太大變化，依舊三大前端框架把持：React，Vue，Angular。從團隊使用情況來看，React、Vue依舊是主流，Angular似乎慢慢不那麼受待見，也許太難學了吧(手動捂臉)

React 16.x上半年發佈，推出了不少新特性，例如hooks、lazy、suspense等等，如果是React技術棧的同學鼓勵第一時間進行嘗試。hooks還需要再多多實踐，整體實現理念和原有class方式有很大不同，習慣了原有的生命週期的寫法的同學還需要適應。

Vue 3.x難產至今，根據路線圖3.0會有大量的更新，比如virtual dom的重寫、框架會更小更快、全面擁抱TypeScript、使用Proxy來實現檢測機制等等。呼喚尤大大趕緊更新，vue的同學恨的牙癢癢的，下半年的KPI就指望這個啦~

Angular近期沒有太多關注，不過Angular是一個真正意義的MVVM框架，不比React或者Vue其實都是View框架，所以這是一個大而全的框架。但是團隊方面期望技術棧進行收斂，所以這方面就沒有太多的投入了。

在框架層，可以持續關注PWA和WebAssembly，PWA對於弱網環境的用戶體驗提升很有幫助，而且還可以作為桌面應用的技術框架。WebAssembly可以讓前端在高密度計算性能上得到很大提升，不過應用場景有限。

上面介紹了大前端關於狀態管理、UI組件、小程序、跨平臺和框架層的內容。下面會繼續介紹編程語言、工程化、監控、測試和服務端，同時也會對下半年大前端可以關注的部分進行展望。

結合個人和團隊經歷對2019上半年做個技術總結，將各類技術框架/語言/工具分作兩個維度：

• 技術採用生命週期
• 技術方向

在2019 stateofcss也有關於CSS特性使用情況的統計，每個特性的外圈代表聽過過的數量，內圈表示真正使用過的數量。

其實CSS特性的使用覆蓋面很大因素取決於瀏覽器的支持程度，瀏覽器支持越好越容易獲得更高的使用率。可以看到幾個高使用率的CSS特性在瀏覽器支持方面都非常好，除去Opera Mini和少量IE11，其他主流瀏覽器都能完美支持。

一個有趣的現象是在佈局方面Flexbox使用率要高於Grid，可能的原因在於在低版本瀏覽器的支持方面Flexbox要更好，但其實在當前主流瀏覽器的支持度上已經沒有區別。另一個因素可能是React Native也是推薦使用Flexbox來做佈局，具有較大的群眾基礎吧。

CSS in JS 的理念應該來自React Native，最開始接觸的時候相當顛覆，在JS文件中直接寫相應的CSS定義，使得組件內聚化達到極致，解決了css全局汙染的問題。在web前端，css in js有很多的實現方式，但目前來看還是比較早期，傳統的Less、Sass的這類css預處理框架已經能夠比較好的解決一些問題，從編程習慣上也一脈相承，因此css in js理念不錯，但要得到推廣還需要時間。

CSS Houdini 提出了一個前無古人的的設想：開放 CSS 的 API 給開發者，開發者可以通過這套接口自行擴展 CSS，並提供相應的工具允許開發者介入瀏覽器渲染引擎的樣式和佈局流程中。簡單的說houdini可以讓大家去寫css 的polyfill從而極大的改善css新特性引入的速度。不過諷刺的是，它本身也需要瀏覽器支持，w3c標準還處於working draft，大多數瀏覽器都還沒很好支持，大家可以期待一下～

工程化

提到工程化先拿騰訊直播團隊分享過的一張圖來鎮樓，很多小夥伴會狹隘的認為工程化就是webpack或者gulp打包而已，其實這個應該涵蓋從項目創建、開發、編譯、打包、測試、發佈、監控全流程。

項目初始化

項目腳手架目前已經非常普遍，例如create-react-app或者vue-cli都是官方標準的腳手架工具。對於一些稍大的公司都建議自己包裝一套自己的腳手架，這樣可以沉澱很多最佳實踐，例如工程目錄結構、lint配置、監控配置、打點配置等等，因此腳手架是落地前端架構標準化不可或缺的一環。

本地開發

lint 的規範一定要在項目初期就落地，可以直接拿airbnb的規範或者再定製化一下。lint可以極大的提升代碼質量，至少從代碼風格來看可以保證統一。

Sonar 的引入可以進一步提升代碼質量，幫助分析出潛在的問題，同時分析代碼的重複率，過長的高數等等，這些都是所謂的代碼bad smell，如果任其發展下去，項目維護成本會直線上升。

Mock

工具的必要性在前後端聯調時就能充分提現，很多時候由於前後端接口定義不清晰導致聯調過程就是一個扯皮過程，如果缺乏mock工具，前端也會淪為後端接口調試的觸發器，前端頁面點一下，後端調試大半天，前端小夥伴們傷不起啊。Mock工具至少要有接口定義和本地mock的能力，能夠極大提升大家研發體驗。

打包

前端工程打包工具強烈推薦

webpack 4

，強大的插件能力能夠讓你做幾乎任何事情。webpack4中引入了更為強大智能的code split能力，能夠極大縮減包大小，經過實踐通常減小幅度都在30%-50%，而且在打包速度上也有很大改進，通常也有30%的提升。

監控

當老闆給你發一個線上問題的截屏，你本地又無法重現，又沒有足夠的日誌，這時候是不是鬱悶，和老闆信任的小船說翻就翻了。

監控從能力來看分為幾個階段：

第一階段：硬件運維能力，例如服務器運行情況，CPU、內存、磁盤、網絡等等，在拓機情況下能夠快速響應。

第二階段：應用服務的監控，例如服務可用性、異常流量監控、頁面接口的響應時間、App crash等等。

第三階段：核心業務指標監控，例如業務核心鏈路數據同比環比的對比等等。

第四階段：全鏈路的數據監控，從客戶端、前端到服務層，到數據層，能夠通過唯一id串聯起來，可以方便回溯用戶操作，重現問題現場。

很顯然要做到監控這四個階段需要做大量的基礎設施，往往大廠都有一套完備的輪子。對於小團隊而言，採用開源方案能夠快速補全能力。

Cat 是美團開源的業界良心監控方案，對於前後端都有不錯的監控能力，數據收集也很完備，能夠提供實時的性能指標、健康狀況、實時告警等數據，在多家互聯網公司也得到實踐，實屬拯救碼農頭髮的必備工具，你值得擁有～

umeng 作為移動端行為分析工具已經有非常廣泛的使用，不過對於大廠而言用戶數據非常關鍵，如果有能力還是建議自研，畢竟用戶的行為數據是核心資產，將來可以基於這些數據做推薦、分析等等有價值的事情。

lighthouse/perf curve/perf budget 這些都是作為性能監控的工具，不僅僅可以得到線上環境真實數據，還能在開發階段提前預警性能問題、落地性能優化的最佳實踐，也是小夥伴們不可或缺的好伴侶～

測試

這裡通常指的是自動化測試而非手工測試，從測試覆蓋範圍可以分為單元測試、UI測試、接口測試和功能自動化測試。我所經歷的公司或團隊，幾乎沒有能把自動化測試能夠做好的，時間和需求頻繁變更往往是最大的藉口，不過程序員內心都不願意寫測試用例的吧（手動捂臉）。

從落地難易程度來看，接口測試和單元測試最好落地，接口不說了難度不高收益還不錯，主要需要對數據準備有些要求。單元測試首推 Jest ，同時還能統計出覆蓋率，但是單元測試要明確好可以測試的範圍，一般業務邏輯和底層通用方法比較適合。所以業務邏輯代碼從UI層代碼抽離非常重要，這時候redux這類狀態管理框架就有了天然優勢了，裡面reducer、action部分就可以單測覆蓋。

UI的測試一般對於組件庫有點幫助，簡單的做法就是通過snapshot進行dom對比，簡單粗暴。功能自動化很少能夠落地，appium或者selenium都是其中翹楚，需要看業務情況，如果有頻繁頁面改動，一開始功能自動化寫的爽，後續維護成本大的驚人，而且由於功能覆蓋時間差，還是需要大量手動測試的。

服務端

自從出現Node之後，前端技術正式進入服務端開發，從而讓前端的小夥伴們可以進行全棧的開發，技術棧的範疇變的更大，對於業務的把控能力也變強了。

Node可以帶來幾個明顯的 好處

第一，可以作為BFF(Backend for Frontend)層，解決前後端接口頻繁變更的問題，通過BFF層可以實現更加靈活的接口，接口字段的過濾，接口的聚合等等

第二，可以用做SSR(Server Side Render)，通過Node層同構直出，可以將前端渲染代碼放在服務端，實現首屏的服務端渲染，提升首屏渲染時間

第三，基於“只要能用JS實現，最終都會用JS實現”定律，Node讓前端同學可以用JS擼後端代碼，這個掌控一切的感覺太爽了~

Node也存在一些 缺點

第一，需要額外的服務器，很多場景下Node層僅僅做接口透傳的工作，對於服務器是一種浪費，而且作為一個核心節點如果一旦掛掉整個應用都不可用

第二，需要對Node服務有一整套的打包、部署、監控等能力，這個對於前端同學來說提出了較高的運維能力的要求，這些事情往往讓前端同學苦不堪言

服務端最近可以持續關注GraphQL/Serverless，這兩項技術對於前後端的架構設計都會帶來深遠的影響。

2019年下半年展望

中後臺的重塑

針對中後臺業務特點，缺乏詳盡的交互設計，缺乏足夠的前端資源，頁面樣式相對統一，業界提出通過少量代碼或者無代碼方式搭建中後臺前端系統。目前有的一些最佳實踐：Fusion Design，飛冰，Ant Design Pro。大家都是從幾個方向去實現中後臺前端系統的無代碼化，Ant Design Pro基於Ant Design提供了一整套中後臺的網站框架和頁面模板，對於快速搭建很有幫助。Fusion Design和飛冰是通過打通設計和編碼環節，直接從sketch文檔導出相應的頁面代碼，也是極大的釋放了前端同學碼頁面的工作量。

Flutter跨平臺解決方案

Flutter作為一個跨多端(iOS，Android，PC，Embedded)，具有

美觀、快速、高效、開放

的特點，目前在閒魚、貝殼、阿里等公司都有落地場景，作為下一代跨平臺解決方案我們可以持續關注，它具有一個非常宏大的野心，背靠Google大廠，能夠從系統底層開始抹平各端差異，具有一個強大的技術架構來支持，長期來看還是挺值得期待的。

阿里前端委員會四大技術方向

以下內容摘抄自圓心的分享文稿

1. 搭建服務 ： 可以看到整個搭建服務無論是在中後臺還是整個無線端，以及 PC 端都有大量場景，這樣大量場景需要把整個框架標準化，希望把裡面的元件、組件以及模塊標準化，還希望把這樣的服務能夠服務於今天所有無論是中後臺也好，C 端頁面也好，希望有這樣的體系——服務化標準化的方式服務，打通整個體系，這就是為什麼把搭建服務認為是面向未來最重要的方向。
2. Serverless ： 可以讓前端更加貼近業務，可以讓更多能力下沉。 前端轉到 Node 體系有一個很大的挑戰，但是到了 Serverless 我們可以不用關注部署，不用關注運維，不需要關注所有的 DevOps，也不需要關注底層數據庫的狀態，他會讓我們前後端整個的體系像前後端分層一樣又往前邁一步。
3. 智能化 ： 因為在 AI 來臨的時候，我們能否從一個 Design 變成一個 Code？ 今天每個公司的前端都有大量的設計、大量原代碼，我們通過大量設計稿和原代碼進行機器學習，讓中間的佈局可學習，讓中間的元件可學習，我相信未來 D2C 一定能夠解決前端生產力瓶頸，讓前端從今天大量低端開發、手工工作中解放出來，將精力轉移到很多領域深度的參與、深度的突破。
4. IDE ： 今天阿里的前端我們做了叫工程中臺，工程中臺做到了前端代碼從提交到發佈的管控，當然包括中間提交之後整個代碼的編譯、構建、檢測以及發佈。 但是在前臺的部分，每個團隊都有一個工具，而這個工具在各團隊之間割裂的，無法複用。 因為工程不僅僅是提交到發佈，前端工程化應該從編碼開始到發佈，應該是一個完整的鏈路、完整的格局

前端技術棧標準化

前端發展到現在，整個技術棧依舊處於百花齊放的階段，但是對於公司或者團隊而言，需要逐步從草莽時代走向正規軍時代，這就需要在技術棧標準化上做一些事情。例如對於一個10人左右的前端團隊而言，如果還是三大前端框架並存，那麼技術沉澱、代碼複用都無從談起。所以對於一個前端團隊而言，標準化的技術棧是非常重要的，需要統一的腳手架、lint配置、mock工具、編程語言、框架、監控等等。

寫在最後

大前端的技術非常繁雜，由於個人和團隊精力有限，總是有不少遺漏還需要各位小夥伴們補充。對於各個技術所處的採用生命週期也限於個人的體驗，總是難免有些爭議，我只能儘可能做到相對合理。

將各個技術放在不同的生命週期中，本意不是去貶低某項技術，其實恰恰相反，能夠出現在Laggards週期往往說明這個技術得到歲月的洗禮，經過長時間的驗證。只是一個時代總是有一個時代主流的技術，這個總結期望大家能夠不斷自省審視當前的技術棧，保持在業界主流對於未來項目維護、吸引人才都是很有幫助的。

無論什麼樣的技術總會有過時的那一天，身為碼農還是要持續不斷學習，不要僅僅修煉術的方面停留在各種技術的使用之上，還要多多修煉道的方面，能夠撥開技術的表面，看清它背後的原理以及解決問題的本質。

【End】