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

大前端

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 (
      <div>
        <h1>{this.count}</h1>
        <button onClick={() => this.up()}>+</button>
        <button onClick={() => this.down()}>-</button>
      </div>
    )
  }
}
 
Vue.render(<App />, document.body as HTMLElement)

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

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

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

另外還有 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 component
class 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`<p>Hello, ${this.name}!</p>`;
  }
}
 
// Register the element with the browser
customElements.define('custom-greeting', CustomGreeting);

是否是看着更眼熟了？

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

前端從 2014 年到 2017 年是混戰期，得益於 Node.js 的輔助加成，外加各類前端優秀的創意和實踐，使得 React/Vue/Angular 三足鼎立。不管 React 發佈 v16，增長 Fiber 和 Hooks，仍是 Vue 3.0 發佈，其實最終都是朝着 W3C WebComponents 標準走。一言以蔽之，Follow 標準是趨勢，若是可以引領標準，那將是框架的無上榮耀。

咱們能夠參考一下技術成熟度曲線（Hype Cycle -Wikipedia），這個曲線把技術發展分紅五個步驟：

【科技誕生的促動期】->【太高指望的峯值】-> 【泡沫化的底谷期】 -> 【穩步爬升的光明期】 -> 【實質生產的高原期】。

從前端如今的熱度來看，應該是處於從第三階段【泡沫化的底谷期】到第四階段【穩步爬升的光明期】的爬坡過程，創新不會那麼多，更多的是偏於應用層的內容。

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

有句話叫作「方法不對，努力白費」全部的前端大神都有本身的學習方法，而學web前端的學習也基本一致，而對於一個什麼都不懂的初學者，根本不會知道該怎麼學，這也是形成失敗的最直接緣由。因此學web前端必定要有人指點。若是你處在迷茫期，找不到方向。能夠加入咱們的前端學習交流qun： 784783012 。有任何不明白的東西隨時來問我。點擊： 前端學習圈

應用層封裝進入爆發期

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

舉個例子 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/VSCode 的火爆，帶動了 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 > Node.js > nw.js > atom(electron) > 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 的超集，包括 ES五、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 & 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 真的可以替人寫代碼，能應變的人天然也是不怕的。

關於大前端的現狀和將來我就分享到這裏，但願能對你有所幫助。