在上一篇文章中已經介紹了大前端關於狀態管理、UI組件、小程序、跨平臺和框架層的內容。在本文中，我會繼續介紹編程語言、工程化、監控、測試和服務端，同時也會對下半年大前端能夠關注的部分進行展望。javascript
結合我的和團隊經歷對2019上半年作個技術總結，將各種技術框架/語言/工具分做兩個維度：css
來自
statesofjs的統計，在類JS編程語言上，ES6遙遙領先，TypeScript也得到接近半數的使用量。其次是Flow、Reason、Elm和ClojureScript。
目前主流編程語言已是ES6/7+Babel的組合，用過ES6/7後基本無法再回到原始的ES5時代了，出現了類和模塊的概念方便JS代碼模塊化加載，再加上各類語法糖用的快樂的飛起。async await的語法也替代promise的寫法，使得代碼邏輯變得更加簡潔。ES的規範依舊在快速迭代，每一年都會出一個更新的版本，引入很多語言特性，同時有Babel加持能夠將新的語法都轉譯成ES5版本運行在瀏覽器中。html
在2019 stateofcss也有關於CSS特性使用狀況的統計，每一個特性的外圈表明聽過過的數量，內圈表示真正使用過的數量。前端
其實CSS特性的使用覆蓋面很大因素取決於瀏覽器的支持程度，瀏覽器支持越好越容易得到更高的使用率。能夠看到幾個高使用率的CSS特性在瀏覽器支持方面都很是好，除去Opera Mini和少許IE11，其餘主流瀏覽器都能完美支持。vue
一個有趣的現象是在佈局方面Flexbox使用率要高於Grid，可能的緣由在於在低版本瀏覽器的支持方面Flexbox要更好，但其實在當前主流瀏覽器的支持度上已經沒有區別。另外一個因素多是React Native也是推薦使用Flexbox來作佈局，具備較大的羣衆基礎吧。java
CSS in JS的理念應該來自React Native，最開始接觸的時候至關顛覆，在JS文件中直接寫相應的CSS定義，使得組件內聚化達到極致，解決了css全局污染的問題。在web前端，css in js有不少的實現方式，但目前來看仍是比較早期，傳統的Less、Sass的這類css預處理框架已經可以比較好的解決一些問題，從編程習慣上也一脈相承，所以css in js理念不錯，但要獲得推廣還須要時間。react
CSS Houdini 提出了一個前無古人的的設想：開放 CSS 的 API 給開發者，開發者能夠經過這套接口自行擴展 CSS，並提供相應的工具容許開發者介入瀏覽器渲染引擎的樣式和佈局流程中。簡單的說houdini可讓你們去寫css 的polyfill從而極大的改善css新特性引入的速度。不過諷刺的是，它自己也須要瀏覽器支持，w3c標準還處於working draft，大多數瀏覽器都還沒很好支持，你們能夠期待一下～webpack
提到工程化先拿騰訊直播團隊分享過的一張圖來鎮樓，不少小夥伴會狹隘的認爲工程化就是webpack或者gulp打包而已，其實這個應該涵蓋從項目建立、開發、編譯、打包、測試、發佈、監控全流程。程序員
項目初始化 項目腳手架目前已經很是廣泛，例如create-react-app或者vue-cli都是官方標準的腳手架工具。對於一些稍大的公司都建議本身包裝一套本身的腳手架，這樣能夠沉澱不少最佳實踐，例如工程目錄結構、lint配置、監控配置、打點配置等等，所以腳手架是落地前端架構標準化不可或缺的一環。web
本地開發 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，這兩項技術對於先後端的架構設計都會帶來深遠的影響。
中後臺的重塑 針對中後臺業務特色，缺少詳盡的交互設計，缺少足夠的前端資源，頁面樣式相對統一，業界提出經過少許代碼或者無代碼方式搭建中後臺前端系統。目前有的一些最佳實踐：Fusion Design，飛冰，Ant Design Pro。你們都是從幾個方向去實現中後臺前端系統的無代碼化，Ant Design Pro基於Ant Design提供了一整套中後臺的網站框架和頁面模板，對於快速搭建頗有幫助。Fusion Design和飛冰是經過打通設計和編碼環節，直接從sketch文檔導出相應的頁面代碼，也是極大的釋放了前端同窗碼頁面的工做量。
Flutter跨平臺解決方案 Flutter做爲一個跨多端(iOS，Android，PC，Embedded)，具備美觀、快速、高效、開放的特色，目前在閒魚、貝殼、阿里等公司都有落地場景，做爲下一代跨平臺解決方案咱們能夠持續關注，它具備一個很是宏大的野心，背靠Google大廠，可以從系統底層開始抹平各端差別，具備一個強大的技術架構來支持，長期來看仍是挺值得期待的。
阿里前端委員會四大技術方向 如下內容摘抄自圓心的分享文稿
搭建服務：能夠看到整個搭建服務不管是在中後臺仍是整個無線端，以及 PC 端都有大量場景，這樣大量場景須要把整個框架標準化，但願把裏面的元件、組件以及模塊標準化，還但願把這樣的服務可以服務於今天全部不管是中後臺也好，C 端頁面也好，但願有這樣的體系——服務化標準化的方式服務，打通整個體系，這就是爲何把搭建服務認爲是面向將來最重要的方向。
Serverless：可讓前端更加貼近業務，可讓更多能力下沉。前端轉到 Node 體系有一個很大的挑戰，可是到了 Serverless 咱們能夠不用關注部署，不用關注運維，不須要關注全部的 DevOps，也不須要關注底層數據庫的狀態，他會讓咱們先後端整個的體系像先後端分層同樣又往前邁一步。
智能化：由於在 AI 來臨的時候，咱們可否從一個 Design 變成一個 Code？今天每一個公司的前端都有大量的設計、大量原代碼，咱們經過大量設計稿和原代碼進行機器學習，讓中間的佈局可學習，讓中間的元件可學習，我相信將來 D2C 必定可以解決前端生產力瓶頸，讓前端從今天大量低端開發、手工工做中解放出來，將精力轉移到不少領域深度的參與、深度的突破。
IDE：今天阿里的前端咱們作了叫工程中臺，工程中臺作到了前端代碼從提交到發佈的管控，固然包括中間提交以後整個代碼的編譯、構建、檢測以及發佈。可是在前臺的部分，每一個團隊都有一個工具，而這個工具在各團隊之間割裂的，沒法複用。由於工程不只僅是提交到發佈，前端工程化應該從編碼開始到發佈，應該是一個完整的鏈路、完整的格局
前端技術棧標準化 前端發展到如今，整個技術棧依舊處於百花齊放的階段，可是對於公司或者團隊而言，須要逐步從草莽時代走向正規軍時代，這就須要在技術棧標準化上作一些事情。例如對於一個10人左右的前端團隊而言，若是仍是三大前端框架並存，那麼技術沉澱、代碼複用都無從談起。因此對於一個前端團隊而言，標準化的技術棧是很是重要的，須要統一的腳手架、lint配置、mock工具、編程語言、框架、監控等等。
大前端的技術很是繁雜，因爲我的和團隊精力有限，老是有很多遺漏還須要各位小夥伴們補充。對於各個技術所處的採用生命週期也限於我的的體驗，老是不免有些爭議，我只能儘量作到相對合理。
將各個技術放在不一樣的生命週期中，本意不是去貶低某項技術，其實偏偏相反，可以出如今Laggards週期每每說明這個技術獲得歲月的洗禮，通過長時間的驗證。只是一個時代老是有一個時代主流的技術，這個總結指望你們可以不斷自省審視當前的技術棧，保持在業界主流對於將來項目維護、吸引人才都是頗有幫助的。
不管什麼樣的技術總會有過期的那一天，身爲碼農仍是要持續不斷學習，不要僅僅修煉術的方面停留在各類技術的使用之上，還要多多修煉道的方面，可以撥開技術的表面，看清它背後的原理以及解決問題的本質。
有興趣同窗能夠關注微信公衆號奶爸碼農，不按期分享關於投資、理財、IT的信息：