2019年大前端技術趨勢深度解讀

本文首發於極客時間《技術領導力300講》專欄。

大家好，我是阿里巴巴前端技術專家狼叔，今天想跟你們分享2019年我對前端現狀及未來發展趨勢的理解。

我其實特別反感很多人說“前端娛樂圈”這種話，誠然，爆發式增長必然會帶來焦點，但也不必過度解讀，2018年的幾件大事兒我都瞭解，真的不是大家看到的那樣的。學會辯證的看問題，用心去體味背後的趨勢，我想這比所謂的“正直”更有價值，我更希望大家能夠堅持學習，保持思辨和平和。

大前端

2018年的事兒特別多，從React v16普及，到jQuery被GitHub下掉完成階段性歷史使命，在唏噓之外，版本帝AngularJS又釋出了v6和v7兩個版本。這些其實都不算啥大新聞，反觀三大框架，寫法越來越像，越來越貼近WebComponents標準，而周邊應用層面的封裝已經開始指數級增長。小程式是今年最火的技術，接連出現，快應用也想分一杯羹。PWA進入穩定期，尤其是PWA桌面版，可以讓我們更好的看清楚PC桌面版開發的全貌。移動端還是以強運營為主，各大公司都開始不再all in移動，開始重視多端並進，到了開始拼細節的階段了。TypeScript全面開花，GraphQL蠢蠢欲動，WebAssembly更是開啟了瀏覽器上多語言的大門。所有的這一切都在暗示，瀏覽器即作業系統，你能想象到未來前端的樣子麼？下面跟著我一一進行解讀吧。

三大框架標準化

有朋友吐槽：“Vue的特點就是上手快，初期相當好用，但如果接手一個別人寫的 Vue 專案，再和 React 對比一下，你會感謝 React 的”。但當Vue 3.0釋出之後，估計他就不會這樣說了。因為Vue 3的Class API 和 React 的寫法幾乎是一模一樣的，這個改動不是 Proxy 和 TypeScript，而是支援原生 Class 的寫法。你用 Class 來寫，那程式碼和 React 寫法幾乎是一模一樣的！

import Vue from 'vue'class App extends Vue.Component {  count = 0  up() {    this.count++  }  down() {    this.count--  }  render() {    return (      \u0026lt;div\u0026gt;        \u0026lt;h1\u0026gt;{this.count}\u0026lt;/h1\u0026gt;        \u0026lt;button onClick={() =\u0026gt; this.up()}\u0026gt;+\u0026lt;/button\u0026gt;        \u0026lt;button onClick={() =\u0026gt; this.down()}\u0026gt;-\u0026lt;/button\u0026gt;      \u0026lt;/div\u0026gt;    )  }}Vue.render(\u0026lt;App /\u0026gt;, document.body as HTMLElement)

從上面的討論可以看出，前端三大框架已經趨於平穩化、標準化，在我看來未來是WebComponents的。

WebComponents是規範，最早最\u0008知名的一個是 Google 主推的JavaScript 庫Polymer，它可幫助我們建立自定義的可重用 HTML 元素，並使用它們來構建高效能、可維護的 App。在 I/O 大會上，Google 推出了 Polymer 3.0，Polymer 3.0 致力於將 Web 元件的生態系統從 HUML Imports 轉移到 ES Modules，包管理系統將支援 npm，這使你更容易將基於 Polymer 的 Web 元件和你喜歡的工具、框架協同使用。

 \u0026lt;script src=\u0026quot;node_modules/@webcomponents/webcomponents-loader.js\u0026quot;\u0026gt;\u0026lt;/script\u0026gt;  \u0026lt;script type=\u0026quot;module\u0026quot;\u0026gt;    import {PolymerElement, html} from '@polymer/polymer';    class MyElement extends PolymerElement {      static get properties() { return { mood: String }}      static get template() {        return html`          \u0026lt;style\u0026gt; .mood { color: green; } \u0026lt;/style\u0026gt;          Web Components are \u0026lt;span class=\u0026quot;mood\u0026quot;\u0026gt;[[mood]]\u0026lt;/span\u0026gt;!        `;      }    }    customElements.define('my-element', MyElement);  \u0026lt;/script\u0026gt;  \u0026lt;my-element mood=\u0026quot;happy\u0026quot;\u0026gt;\u0026lt;/my-element\u0026gt;  

另外還有2個專案具有一定的參考價值：

1.Rax也提供了一個名為atag的UI WebComponents庫。

2.LitElement是一個簡單的輕量級的快速建立WebComponents的基類，可以理解成是Polymer最小的實現版本。

LitElement主要的特性包括WebComponent生命週期模型支援和單向的資料繫結模型。它遵守 WebComponents 標準，使用lit-html模組這個快速的HTML渲染引擎定義和渲染HTML模板。最重要的是它對瀏覽器相容性非常好，對主流瀏覽器都能有非常好的支援。由於LitHtml基於tagged template，結合ES6中的template，使得它無需預編譯、預處理，就能獲得瀏覽器原生支援，並且擴充套件能力更強，效能更好。

import { LitElement, html } from '@polymer/lit-element'; // Create your custom componentclass CustomGreeting extends LitElement {  // Declare properties  static get properties() {    return {      name: { type: String }    };  }  // Initialize properties  constructor() {    super();    this.name = 'World';  }  // Define a template  render() {    return html`\u0026lt;p\u0026gt;Hello, ${this.name}!\u0026lt;/p\u0026gt;`;  }}// Register the element with the browsercustomElements.define('custom-greeting', CustomGreeting);

是不是看著更眼熟了？

《三國演義》裡有這樣一句：“話說天下大勢，分久必合，合久必分。週末七國分爭，併入於秦。及秦滅之後，楚、漢分爭，又併入於漢。漢朝自高祖斬白蛇而起義，一統天下，後來光武中興，傳至獻帝，遂分為三國。”

前端從2014年到2017年是混戰期，得益於Node.js的輔助加成，外加各種前端優秀的創意和實踐，使得React/Vue/Angular三足鼎立。無論React釋出v16，增加Fiber和Hooks，還是Vue 3.0釋出，其實最終都是朝著W3C WebComponents標準走。一言以蔽之，Follow標準是趨勢，如果能夠引領標準，那將是框架的無上榮耀。

我們可以參考一下技術成熟度曲線（Hype Cycle -Wikipedia），這個曲線把技術發展分成五個步驟：【科技誕生的促動期】-\u0026gt;【過高期望的峰值】-\u0026gt; 【泡沫化的底谷期】 -\u0026gt; 【穩步爬升的光明期】 -\u0026gt; 【實質生產的高原期】。從前端現在的熱度來看，應該是處於從第三階段【泡沫化的底谷期】到第四階段【穩步爬升的光明期】的爬坡過程，創新不會那麼多，更多的是偏於應用層的內容。

對於當下的前端發展情況，我其實是有隱憂的。當年Java世界曾經搞各種GUI，創造了MVC模式，結果沒火，沒想到到了Web開發領域，MVC成了基本約定。之後Model 1和Model 2等企業開發模型漸漸成熟，出現了Struts、Spring、Hibernate三大框架。在之後很長的一段時間裡，Java程式設計師都是言必稱“SSH”。再之後Spring一家獨大，一統江湖，恐怕今天還記得 EJB 的人已經不多了。框架一旦穩定，就會有大量培訓跟進，導致規模化開發。這是把雙刃劍，能滿足企業開發和招人的問題，但也給創新探索領域上了枷鎖。

應用層封裝進入爆發期

框架和工程化基本探索穩定後，大家就開始思考如何更好的用，更簡單的用。目前，各家大廠都在前端技術棧思考如何選型和降低成本，統一技術棧。

舉個例子Umi，Umi 就是一套零配置（約定高於配製），按最佳實踐進行開發的，開箱即用的前端框架: React 全家桶 + dva + jest + antd (mobile) + less + eslint。如下圖所示：

從上圖中可以看出，Umi已經思考的相對全面，從技術選型、構建到多端輸出、效能優化、釋出等方面進行了拆分，使得Umi的邊界更為清晰，是前端最佳實踐，目前大多數前端組都是類似的實現方式。說白了，Umi和 create-react-app（cra）類似，就是現有技術棧的組合，封裝細節，讓開發者用起來更簡單，只寫業務程式碼就可以了。

• 零配置就是預設選型都給你做好了。

• 開箱即用就是技術棧都固化了。

• 約定大於配置，開發模式也固化好了。

Umi的核心是 af-webpack模組，它封裝了Webpack和各種外掛，把 webpack-dev-server 等Node.js模組直接打包進去，同時對配置做了更好的處理以及外掛化。af-webpack核心是webpack-chain模組，通過鏈式寫法來修改Webpack配置，使得af-webpack極為靈活。其實以React全家桶為例，開發者最大的負擔就是Webpack工程化構建。關於 Webpack 的封裝實踐有很多，比如知名的還有YKit、EasyWebpack等。

• YKit 是去哪兒開源的Webpack，內建 Connect 作為Web server，結合dev和hot中介軟體，對於多專案構建提效明顯，對版本檔案釋出有不錯的實踐。

• EasyWebpack 也是外掛化，但對解決方案、boilerplate 等做了非常多的整合，比如Egg的SSR是有深入思考的，儘管不贊同這種做法。

另外，在 create-react-app（cra）專案裡使用的是 react-scripts 作為啟動指令碼，它和 egg-scripts 類似，也是通過約定，隱藏具體實現細節，讓開發者不需要關注構建。在未來，類似的封裝還會有更多的封裝，並且更偏於應用層面。

PWA進入穩定期

PWA和native app（移動應用）的核心區別在於以下幾點：

1.安裝：PWA是一個不需要下載安裝即可使用的應用。

2.快取使用：native app主要是對sqlite快取，以及檔案讀寫操作，而PWA對快取資料庫操作支援的非常好，足以應對各種場景。

3.基本能力補齊，比如推送。

現在PWA已經支援的很好了，唯一麻煩的是快取策略和發版比較麻煩，應用輕量化的趨勢已經很明朗了。下面講一下PWA的一些關鍵點。

1.通用本地儲存的解決方案Workbox

Workbox 是 GoogleChrome 團隊推出的一套 Web App 靜態資源和請求結果本地儲存的解決方案，該解決方案包含一些 JS 庫和構建工具，Workbox 背後則是 Service Worker 和 Cache API 等技術和標準在驅動。在 Workbox 之前，GoogleChrome 團隊較早時間推出過 sw-precache 和 sw-toolbox 庫，但罵聲很多，直到 Workbox 才真正誕生了能方便統一的處理離線能力的更完美的方案。

Workbox 現在已經發布到了 3.0 版本，不管你的站點是用何種方式構建的，它都可以為你的站點提供離線訪問能力，幾乎不用考慮太多的具體實現，只用做一些配置就可以。就算你不考慮離線能力，它也能讓你的站點訪問速度更快。

比如星巴克的PWA應用，對快取的應用高達41.3mb。這是瀏覽器端非常大的突破，儘管沒啥新技術。

2.PWA桌面版

縱觀PC桌面端的發展過程，早期Delphi/VB/VF/VC等構建起的c/s時代，即使到今天依然有很大的量。最近兩年，隨著Atom/\u0008VSCode的火爆，帶動了node webkit相關模組的爆發，比如NW.js和Electron等。通過Web技術來構建pc client，確實是省時省力，使用者體驗也非常好，比如釘釘客戶端、石墨文件客戶端等，最主要的是可以統一技術棧，比如某些演算法，用JS寫一次，之後可以到前端、node、pc client等多處複用。當然更好的是使用Web技術進行開發，不需要加殼打包，PWA桌面版就是這樣的技術。

接下來就具體聊一下桌面端的3個發展階段。

第一階段：原生開發Native

早年的VB/VF/VC/Delphi等原生開發方式，到後來出現QT類的跨平臺軟體，但依然可以理解成是原生開發。

第二階段：混搭開發Hybrid

谷歌於2008年9月2日首次釋出了Chrome瀏覽器，Node.js是Ryan Dahl於2009年釋出的，他把V8引擎（Chrome核心JavaScript引擎）搬到了後端，使用js編寫伺服器程式變為現實。隨後 npm 發展極為迅猛，跨平臺技術也突飛猛進，出現了NW.js這樣的輕量級跨平臺框架，基於Chromium（Chrome開源版本） + Node.js，使得PC桌面端能夠通過Web開發技術開發，最終打包編譯成各個平臺支援的應用格式，給PC桌面開發帶來了太多的可能性。

而Atom 是 GitHub 在 2014 年釋出的一款基於 Web 技術構建的文字編輯器，其中atom-shell，也就是後來的 Electron，是和NW.js類似的技術。它允許使用Node.js（作為後端）和Chromium（作為前端）來完成桌面GUI應用程式的開發。Chromium 提供了渲染頁面和響應使用者互動的能力，而 Node.js 提供了訪問本地檔案系統和網路的能力，也可以使用 NPM 上的幾十萬個第三方包。在此基礎之上，Electron 還提供了 Mac、Windows、Linux 三個平臺上的一些原生 API，例如全域性快捷鍵、檔案選擇框、托盤圖示和通知、剪貼簿、選單欄等。

Erich Gamma老爺子設計的 Monaco/VS Code，同樣基於Electron，但效能比Atom強多了。VS Code 會先啟動一個後臺程式，也就是 Electron 的主程式，它負責編輯器的生命週期管理、程式間通訊、UI外掛管理、升級和配置管理等。後臺程式會啟動一個（或多個）渲染程式，用於展示編輯器視窗，它負責編輯器的整個 UI 部分，包括元件、主題、佈局管理等等。每個編輯器視窗都會啟動一個 Node.JS 子程式作為外掛的宿主程式，在獨立程式裡跑外掛邏輯，然後通過事件或者回撥的方式通知 Renderer 結果，避免了 Renderer 的渲染被外掛中 JS 邏輯阻塞。

演進過程：chrome \u0026gt; Node.js \u0026gt; nw.js \u0026gt; atom(electron) \u0026gt; vs code

在第二階段裡，我們可以看到PC桌面端以 Web 開發技術作為核心，以瀏覽器核心作為跨平臺核心，最終將 Web 開發的程式碼和瀏覽器核心打包。這樣做的好處是前端開發相對簡單，相對於 C++ 等語言更為方便，另外從成本上考慮，也是極為划算的。

如今，很多應用都開始基於Electron構建，比如微信小程式ide、微信pc版本等，另外非常令人激動的是，2018年10月18日，迅雷論壇發文稱新版（從迅雷X 10.1版本開始）採用Electron軟體框架完全重寫了迅雷主介面。使用新框架的迅雷X可以完美支援2K、4K等高清螢幕，介面中的文字渲染也更加清晰銳利。從技術層面來說，新框架的介面繪製、事件處理等方面比老框架更加靈活高效，因此介面的流暢度也顯著優於老框架的迅雷。

第三階段：PWA桌面版

王國維在《人間詞話》中提出“隔與不隔”這一文學命題，這個問題在開發領域也是存在的。明明是Web開發的，為什麼還要打包加殼呢？除了體積非常大以外，使用安裝也極為麻煩。

Spotify的PWA桌面版應用體驗是非常好的，在mac上絲般順滑。

2018年Google IO大會上，微軟宣佈win10全力擁抱PWA，通過爬蟲爬取PWA頁面，並將其轉換為Appx，繼而在其應用商店裡提供應用，體驗和原生Native應用非常相近，對此我非常看好。

瀏覽器有著超強的快取能力，外加PWA其他功能，使得瀏覽器上的PWA應用能夠取得媲美 Native 應用的效能。在瀏覽器裡可以直接開啟，無需加殼，很明顯這是極為方便的。

PWA 必然會改變前端與移動端之間的格局，再加之 AOT(ahead-of-time) 與 WebAssembly 為 JS 帶來的效能上的突破，JavaScript 將撼動所有領域，從移動端（PWA）到桌面應用、物聯網、VR、AR、遊戲乃至人工智慧等等。

Google接下來會大力推進PWA的桌面版，再加上win10和Chrome加持，Web應用無需加殼就能達到近乎原生的體驗，前端的領域再一次被拓寬，未來真的可以大膽的想想。

很多人問PWA在國內為什麼感覺不火，原因很簡單，PWA在弱網環境下表現極好，但中國的網路是全球最好的，所以PWA其實沒有給我們帶來那麼大的收益。不過當做一個補位方案也挺好的，畢竟2G/3G還有點量，另外在伺服器渲染SSR上，PWA也能夠起到很好的效果。

小程式火爆

如果說和PWA比較像的，大概就是小程式了，小程式也可以說是今年最火的技術。

微信小程式的下一步計劃，支援NPM、小程式雲、視覺化程式設計、支援分包等，聽起來很美好，但坑依然不少。小程式原生提供的 DSL 不夠好用，所以就有了上層開發框架或者腳手架來優化開發效率，目前比較主流的有3個：

今年還冒出了微信小程式之外的頭條小程式、支付寶小程式、百度智慧小程式等，未來還會有很多。同時，手機廠商大概是看到了小程式對其應用商店的威脅，小米、華為、OPPO、vivo 等九大國內手機廠商聯手成立了“快應用聯盟”，基於react-native技術棧，整體也很不錯，尤其是天貓呼叫菜鳥裹裹的快應用，安卓下有非常好的體驗。相較而言，微信是基於 Webview 的，而快應用使用的是原生渲染方案，其他家也大抵如此。

其實5G時代很快就到了，大家可以暢想一下，在網速、記憶體和CPU更高的情況下，5G每秒最高下載速度高達1.4G，秒下PWA或小程式應用，到底是離線，還是線上，猶未可知吧。

前端能講的東西實在太多了，但受限於篇幅，本文只能先簡單跟你分享React/Vue/Angular三大框架標準化、應用層封裝進入爆發期、PWA進入穩定期、小程式火爆等方面的內容。下一篇文章中，我將繼續跟你聊聊移動端局面、多端拉齊的必然性等內容，以及2019年不可忽視的TypeScript和WebAssembly這兩大技術，歡迎繼續關注，也歡迎留言與我多多交流。

多端拉齊，並重使用者體驗

在AI時代，沒有“端”的支援可以麼？明顯是不可以的。首先感謝蘋果，將使用者體驗提升到了前無古人的位置。移動網際網路興起後，PC Web日漸沒落。我個人非常欣賞玉伯，在當年無線 ALL IN 戰略中，他還是選擇留下來繼續做 PC Web 的前端。不過，雖然很多公司的重點轉向無線，但 PC 業務也一直沒停，這是很多公司的現狀，也是客觀事實。那麼，PC端這樣的“老古董”的出路到底在哪裡呢？

1.我們可以利用PC/H5快速發版本的優勢，快速驗證AI演算法，繼而為移動端提供更好的模型和資料上的支撐。

2.多端對齊，打好組合拳。既然不能在移動端有更大的突破，大家只能在細節上血拼。

大家的戰場已經不是點了，已經升級到打組合策略的階段了。未來一定是多端拉齊，並重使用者體驗的。

今天的大前端，除了Web外，還包括各種端，比如移動端、OTT，甚至是一些新的物聯網裝置。我們有理由相信Chrome OS當年的遠見：“給我一個瀏覽器，我就能給你一個世界。”如果說的苟且一點：“給我一個Webview，我就能給你一個世界。”

TypeScript

我之前就非常關注TypeScript，但遲遲未下定決心在團隊內落地。今年1月份北京Node Party上組了個局，和幾位嘉賓一起聊了一下，確認提效非常明顯，落地難度也不大，大家一致認為2019年TypeScript將有非常大的增長。本身前端團隊變大，規模化程式設計也必然依賴型別系統和麵向物件的，從這點上看，TypeScript也是完勝的。

這裡再簡單介紹一下TypeScript，它是有型別定義的 JavaScript 的超集，包括 ES5、ES5+ 和其他一些諸如反射、泛型、型別定義、名稱空間等特徵的集合，為了大規模 JavaScript 應用開發而生。複雜軟體需要用複雜的設計，物件導向就是一種很好的設計方式，使用 TypeScript 的一大好處就是 TypeScript 提供了業界認可的類（ ES5+ 也支援）、泛型、封裝、介面物件導向設計能力，以提升 JavaScript 的物件導向設計能力。市面上的框架也對TypeScript提供了非常好的支援。

React 對.tsx支援非常好，比如我在Midway controller裡支援tsx寫法，這是非常大膽的，對於後面react ssr來說是一個極大便利；
Vue 從v2.5.0之後對ts支援就非常好；
Node.js Web框架，尤其是Egg.js對ts支援非常好，當然還有更高階更專注的的Midway框架，Midway基於Egg生態，同時提供IoC等高階玩法；

在使用 Webpack 編譯前端應用式，通過TypeScript-loader可以很輕鬆地將 TypeScript 引入到 Webpack 中。有了 TypeScript-loader，就可以一邊使用 TypeScript 編寫新程式碼，一邊零碎地更新老程式碼。畢竟ts是js超集，你有空就改，非強制，特別包容。

WebAssembly

WebAssembly 是一種新的位元組碼格式，目前主流瀏覽器都已經支援 WebAssembly。 和 JS 需要解釋執行不同的是，WebAssembly 位元組碼和底層機器碼很相似，可以快速裝載執行，因此效能相對於 JS 解釋執行而言有了極大的提升。 也就是說 WebAssembly 並不是一門程式語言，而是一份位元組碼標準，需要用高階程式語言編譯出位元組碼放到 WebAssembly 虛擬機器中才能執行， 瀏覽器廠商需要做的就是根據 WebAssembly 規範實現虛擬機器。這很像Java早年的Applet，能夠讓其他語言執行在瀏覽器裡。Applet 是一種Java 程式，它可以執行在支援Java 的Web 瀏覽器內。因為它有完整的Java API支援，所以 Applet 是一個全功能的Java 應用程式。

有了WebAssembly，在瀏覽器上可以跑任何語言。從Coffee到TypeScript，到Babel，這些都是需要轉譯為js才能被執行的，而WebAssembly是在瀏覽器裡嵌入vm，直接執行，不需要轉譯，執行效率自然高得多。

舉個例子，AutoCAD軟體是由美國歐特克有限公司（Autodesk）出品的一款自動計算機輔助設計軟體，可以用於繪製二維製圖和基本三維設計。使用它時，無需懂得程式設計，即可自動製圖，因此它在全球被廣泛應用於土木建築、裝飾裝潢、工業製圖、工程製圖、電子工業、服裝加工等諸多領域。

AutoCAD是由大量C++程式碼編寫的軟體，經歷了非常多的技術變革，從桌面到移動端再到web。之前，InfoQ上有一個演講，題目是《AutoCAD \u0026amp; WebAssembly: Moving a 30 Year Code Base to the Web》，即通過WebAssembly，讓很多年代久遠的C++程式碼在Web上可以執行，並且保證了執行效率。

本來，我以為WebAssembly離我們很遠，但在2018年Google I/O大會親眼見到AutoCad Web應用後，非常震撼，效果如下圖所示。

能夠讓如此龐大的專案跑在Web端，真的是非常了不起。通過WebAssembly技術，既能複用之前的C++程式碼，又能完成Web化，這也許就是所謂的兩全其美吧。

之前，全民直播的前端研發經理趙洋曾分享了WebAssembly在全民直播裡對直播編解碼方面的應用，效果也非常不錯。

另外，許式偉在 ECUG Con 2018上也分享了一個 Topic，主題是《再談 Go 語言在前端的應用前景》，Go的發展也遇到了瓶頸，專注後端開發是沒辦法讓 Go 排到第一的，目前的一個方向是藉助GopherJS，將Go程式碼編譯為JS。這種實踐是沒問題的，和Kotlin類似，對於絕大部分 Go 使用者也是非常好的。但問題在於，真正的前端不太可能換語言，目前連Babel、ts這種都折騰的心累，更何況切換到Go。“求別更新了，老子學不動了”，這是大部分前端工程師的心聲。

從WebAssembly的現狀來看，對於複雜計算耗時的部分採用其他語言實現，確實是比較好的一種方式。從趨勢上看，WebAssembly讓所有語言都能跑在瀏覽器上，瀏覽器上有了vm，瀏覽器不就是作業系統了嗎？

Chrome的核心JavaScript引擎V8目前已包含了 Liftoff 這一新款 WebAssembly baseline 編譯器。Liftoff 簡單快速的程式碼生成器極大地提升了 WebAssembly 應用的啟動速度。不過在桌面系統上，V8 依然會通過讓 TurboFan 在後臺重新編譯程式碼的方式最終讓程式碼執行效能達到峰值。

目前，V8 v6.9 (Chrome 69) 中的 Liftoff 已經設定為預設工作狀態，也可以顯式地通過 --liftoff/–no-liftoff 或者 chrome://flags/#enable-webassembly-baseline 開關來控制。另外，Node.js v11採用的v8引擎的v7版本，對WebAssembly支援更好，雖然這沒啥意義，但練手還是蠻好的。

移動端

Flutter 是 Google 推出的幫助開發者在 Android 和 iOS 兩個平臺，同時開發高質量原生應用的全新移動 UI 框架，和 React-native/Weex 一樣支援熱更新。Flutter使用Google自己家的Dart語言編寫，剛好今年Dart 2也正式釋出，不知道二者之間是否有關聯。目前Dart主攻Flutter和Web兩塊，同時提供了 pub 包管理器，儼然是一門全新的語言，學習成本有些高。反觀TypeScript就非常容易被接受，基於npm生態，相容ES語法，因此，2019年對Dart我還是會持觀望態度。

除了不喜歡Dart外，Flutter的其他方面都很好，在移動端現在強運營的背景下，支援熱更新是必備能力。

關於Weex，一邊罵一邊用，很無奈的一種狀態。Weex本身是好東西，捐給了Apache，目前在孵化中，會有一個不錯的未來。但社群維護的非常差，問題issue不及時，文件不更新。如果公司沒有架構組，還是比較難搞定的。

不過也有很多不錯的案例，比如2018年優酷雙十一活動就是使用Weex開發的，效果非常不錯。通過自建的視覺化活動搭建平臺，能夠非常高效的完成開發，結合App內的快取，整體效果比H5好的多。

我對 Weex 的看法是，以前 Weex 只是解決H5渲染效率的問題，但如今強運營的背景，使得 Weex 承載了非常多的內容，比如動畫、遊戲甚至是圖形影像處理等。可以看到，未來 Weex 還會戰略性的增加。

總結

總結一下，2018年大前端的現象：

前端三大框架已趨於平穩，標準化，向Web Components看齊。
應用層面開始進入過渡封裝周邊的階段，很多細節都會埋在框架裡。
PWA平穩發展，相容4/5瀏覽器，workbox 3進一步簡化開發，另外PWA桌面版已經開始興起，未來會更多。
多端受到重視，不再只是all in mobile。

WebAssembly讓更多語言可以執行在瀏覽器上，AutoCAD的web版是非常好的例子。

強運營背景下，移動端以前端開發為主，已成定局。Flutter局勢暫不好說，還在觀望中（主要是不喜歡Dart）。

TypeScript落地很好，包容性更好：React 對.tsx支援非常好，Vue 從v2.5.0之後對ts支援就非常好，Node.js（尤其是Egg.js、midway）對ts支援也非常好。

5G時代快來了，網際網路的長期線上情況有可能會被打破。本地裝置即客戶端，可以大膽的想想。對前端來說，本地web服務，輔助日常開發，類似於je這樣的模組會越來越多。

終上所述，未來瀏覽器會越來越重要，Web Os的概念正在慢慢落地。另外三大框架趨於穩定，寫法上也越來越像，學習成本是降低的。但周邊應用層面的封裝還會是爆發式增長，更多複雜的細節會被包裝到應用框架裡，可能還有很多不一樣的開發方式需要大家熟悉。

對於開發者而言，唯一不變的就是學習能力。掌握了學習能力就能夠應對這些趨勢變化，無論是在三大框架混戰時代，還是後面周邊封裝時代都能很開心的“折騰”。哪怕有一天AI真的能夠替人寫程式碼，能應變的人自然也是不怕的。

關於大前端的現狀和未來我就分享到這裡，希望能對你有所幫助。

更多內容，請關注前端之巔。

會議推薦

2019年6月，GMTC全球大前端技術大會2019即將到來。小程式、Flutter、移動AI、工程化、效能優化…大前端的下一站在哪裡？點選下圖瞭解更多詳情。