篇文章主要向大家介紹一個全局命令行輔助開發(fā)工具liftoff，這個工具在npm托管平臺上周下載量還是很大的，但是在工作中卻很少看見有人使用！目前我知道在使用它的構(gòu)建工具有g(shù)ulp和fis3！

liftoff的作用

1、全局命令行（npm install xxx -g）調(diào)用項目目錄下安裝的本地包（npm install xxx）

目前很多的構(gòu)建工具都把自己的功能分成了兩個部分：xxx-cli和xxx，比如gulp和webpack。

拿gulp舉例，在安裝完gulp-cli這個包后，是不能直接使用的，還需要在項目下安裝gulp這個包才行，工具作者的想法就是gulp-cli負責命令行參數(shù)的處理，本地的gulp包才負責具體構(gòu)建邏輯的處理，即gulp-cli會加載本地的gulp包，然后將命令行參數(shù)傳給它！

一個全局命令行調(diào)用本地項目中安裝的包還是比較麻煩的，好在liftoff提供了這個能力（內(nèi)部使用的是resolve這個包完成這個工作）。

2、加載配置

你會發(fā)現(xiàn)gulp、fis3、webpack等等一些構(gòu)建工具都有一個本地的配置文件xxx.config.js，顯然在構(gòu)建工具運行的時候需要讀取這個配置，那么liftoff也提供了這個能力，它還處理了一些特殊的情況，比如配置文件在祖先目錄下或者不在工程目錄下等特殊情況！

3、編譯特殊語言

有時用戶在寫配置文件時，不一定都會用javascript這個語言，如果用了其他語言開發(fā)了配置文件，node是無法加載的，所以需要先加載編譯腳本使其先被編譯，而liftoff就提供了這個能力，在使用特殊語言時可以先加載編譯腳本！

liftoff的主要API

var Liftoff=require('liftoff'); //調(diào)用

var cli=new Liftoff(options);//實例化

cli.prepare(options, fn); //處理參數(shù)

cli.execute(options, fn); //執(zhí)行回調(diào)函數(shù)

cli.launch(options, fn); //上面兩個方法的組合

liftoff的使用詳解

假設(shè)我們現(xiàn)在提前為百度寫一個fis4（目前只有fis3），配置文件叫fis4-conf.js。

現(xiàn)在我們創(chuàng)建如下這樣的目錄：

index.js是我們命令行的邏輯，本地開發(fā)可以先不發(fā)包，

fis4-conf.js是配置文件，

fis4-local是本地需要安裝的包。

如圖2，在index.js中先實例化liftoff，傳入的對象的屬性在內(nèi)部會被合并到cli這個實例對象上。這個配置中processTitle代表命令行運行后的進程名，moduleName代表這個命令行需要加載的本地的包名，configName代表本地配置的文件名！

如果上面三個屬性都沒傳，只有name屬性，processTitle和moduleName都會復用name的值，name再拼接一個‘file’字符串然后賦給configName。

extensions對象的key代表本地配置文件的后綴，value代表需要加載的編譯腳本，值可以是null、字符串、數(shù)組等，內(nèi)部會將extensions這個字段用fined這個包來解析，所以配置規(guī)則可以參考這個包！

在圖3中我們調(diào)用了prepare方法，require參數(shù)可以是數(shù)組也可以是字符串（包名），代表需要提前加載運行的包；cwd默認是進程運行的目錄，這里通過cwd可以自定義root目錄；configPath參數(shù)可以重新定義配置文件的路徑。

現(xiàn)在我們打印一下后面回調(diào)函數(shù)的參數(shù)env，看看輸出什么？

如圖4，liftoff幫我們找到了本地配置文件的位置和本地需要加載的包fis4-local的位置，說到這里我想大家應該明白了，這些信息既然都拿到了后面怎么運行就看你自己了。

我們再聊聊如何用其他語言開發(fā)配置文件比如ts

我們現(xiàn)在建一個ts配置文件fis4-conf.ts，如圖5所示：

如圖6所示，extensions后綴修改成ts，值變成需要提前加載的編譯包，最后我們調(diào)用execute方法，這個方法不僅會加載extensions中注冊的包，還會加載require中注冊的包！

運行結(jié)果如下：

很好，符合預期。

如果大家不太清楚自己使用的語言對應的編譯腳本，可以使用interpret這個包，如下：

如圖9所示，interpret已經(jīng)為我們整理好了各種后綴對應的編譯腳本的包！

總結(jié)

這篇文章主要分析了liftoff解決加載本地包、加載項目配置文件以及如何加載其他語言的編譯腳本，可以把它當做我們開發(fā)命令行的輔助工具！另外既然我們了解了思路，其實我們也可以手寫這些邏輯，不一定要復用它，造輪子才可以更快的成長！

喜歡我的文章就關(guān)注我吧，后續(xù)會更多干貨輸出，讓我們一起學習，共同成長！（希望收藏之前大家關(guān)注一波-_-）

者｜狼叔

編輯｜覃云

你好，我是阿里巴巴前端技術(shù)專家狼叔，今天想跟你分享 2019 年我對前端現(xiàn)狀及未來發(fā)展趨勢的理解。

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

大前端

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

三大框架標準化

有朋友吐槽：“Vue 的特點就是上手快，初期相當好用，但如果接手一個別人寫的 Vue 項目，再和 React 對比一下，你會感謝 React 的”。但當 Vue 3.0 發(fā)布之后，估計他就不會這樣說了。因為 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)

從上面的討論可以看出，前端三大框架已經(jīng)趨于平穩(wěn)化、標準化，在我看來未來是 WebComponents 的。

WebComponents 是規(guī)范，最早最知名的一個是 Google 主推的 JavaScript 庫 Polymer，它可幫助我們創(chuàng)建自定義的可重用 HTML 元素，并使用它們來構(gòu)建高性能、可維護的 App。在 I/O 大會上，Google 推出了 Polymer 3.0，Polymer 3.0 致力于將 Web 組件的生態(tài)系統(tǒng)從 HUML Imports 轉(zhuǎn)移到 ES Modules，包管理系統(tǒng)將支持 npm，這使你更容易將基于 Polymer 的 Web 組件和你喜歡的工具、框架協(xié)同使用。

 <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 是一個簡單的輕量級的快速創(chuàng)建 WebComponents 的基類，可以理解成是 Polymer 最小的實現(xiàn)版本。

LitElement 主要的特性包括 WebComponent 生命周期模型支持和單向的數(shù)據(jù)綁定模型。它遵守 WebComponents 標準，使用 lit-html 模塊這個快速的 HTML 渲染引擎定義和渲染 HTML 模板。最重要的是它對瀏覽器兼容性非常好，對主流瀏覽器都能有非常好的支持。由于 LitHtml 基于 tagged template，結(jié)合 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);

是不是看著更眼熟了？

《三國演義》里有這樣一句：“話說天下大勢，分久必合，合久必分。周末七國分爭，并入于秦。及秦滅之后，楚、漢分爭，又并入于漢。漢朝自高祖斬白蛇而起義，一統(tǒng)天下，后來光武中興，傳至獻帝，遂分為三國。”

前端從 2014 年到 2017 年是混戰(zhàn)期，得益于 Node.js 的輔助加成，外加各種前端優(yōu)秀的創(chuàng)意和實踐，使得 React/Vue/Angular 三足鼎立。無論 React 發(fā)布 v16，增加 Fiber 和 Hooks，還是 Vue 3.0 發(fā)布，其實最終都是朝著 W3C WebComponents 標準走。一言以蔽之，F(xiàn)ollow 標準是趨勢，如果能夠引領(lǐng)標準，那將是框架的無上榮耀。

我們可以參考一下技術(shù)成熟度曲線（Hype Cycle -Wikipedia），這個曲線把技術(shù)發(fā)展分成五個步驟：【科技誕生的促動期】->【過高期望的峰值】-> 【泡沫化的底谷期】 -> 【穩(wěn)步爬升的光明期】 -> 【實質(zhì)生產(chǎn)的高原期】。從前端現(xiàn)在的熱度來看，應該是處于從第三階段【泡沫化的底谷期】到第四階段【穩(wěn)步爬升的光明期】的爬坡過程，創(chuàng)新不會那么多，更多的是偏于應用層的內(nèi)容。

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

應用層封裝進入爆發(fā)期

框架和工程化基本探索穩(wěn)定后，大家就開始思考如何更好的用，更簡單的用。目前，各家大廠都在前端技術(shù)棧思考如何選型和降低成本，統(tǒng)一技術(shù)棧。

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

從上圖中可以看出，Umi 已經(jīng)思考的相對全面，從技術(shù)選型、構(gòu)建到多端輸出、性能優(yōu)化、發(fā)布等方面進行了拆分，使得 Umi 的邊界更為清晰，是前端最佳實踐，目前大多數(shù)前端組都是類似的實現(xiàn)方式。說白了，Umi 和 create-react-app（cra）類似，就是現(xiàn)有技術(shù)棧的組合，封裝細節(jié)，讓開發(fā)者用起來更簡單，只寫業(yè)務代碼就可以了。

• 零配置就是默認選型都給你做好了。
• 開箱即用就是技術(shù)棧都固化了。
• 約定大于配置，開發(fā)模式也固化好了。

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

• YKit 是去哪兒開源的 Webpack，內(nèi)置 Connect 作為 Web server，結(jié)合 dev 和 hot 中間件，對于多項目構(gòu)建提效明顯，對版本文件發(fā)布有不錯的實踐。
• EasyWebpack 也是插件化，但對解決方案、boilerplate 等做了非常多的集成，比如 Egg 的 SSR 是有深入思考的，盡管不贊同這種做法。

另外，在 create-react-app（cra）項目里使用的是 react-scripts 作為啟動腳本，它和 egg-scripts 類似，也是通過約定，隱藏具體實現(xiàn)細節(jié)，讓開發(fā)者不需要關(guān)注構(gòu)建。在未來，類似的封裝還會有更多的封裝，并且更偏于應用層面。

PWA 進入穩(wěn)定期

PWA 和 native app（移動應用）的核心區(qū)別在于以下幾點：

1. 安裝：PWA 是一個不需要下載安裝即可使用的應用。
2. 緩存使用：native app 主要是對 sqlite 緩存，以及文件讀寫操作，而 PWA 對緩存數(shù)據(jù)庫操作支持的非常好，足以應對各種場景。
3. 基本能力補齊，比如推送。

現(xiàn)在 PWA 已經(jīng)支持的很好了，唯一麻煩的是緩存策略和發(fā)版比較麻煩，應用輕量化的趨勢已經(jīng)很明朗了。下面講一下 PWA 的一些關(guān)鍵點。

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

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

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

比如星巴克的 PWA 應用，對緩存的應用高達 41.3mb。這是瀏覽器端非常大的突破，盡管沒啥新技術(shù)。

2.PWA 桌面版

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

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

第一階段：原生開發(fā) Native

早年的 VB/VF/VC/Delphi 等原生開發(fā)方式，到后來出現(xiàn) QT 類的跨平臺軟件，但依然可以理解成是原生開發(fā)。

第二階段：混搭開發(fā) Hybrid

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

而 Atom 是 GitHub 在 2014 年發(fā)布的一款基于 Web 技術(shù)構(gòu)建的文本編輯器，其中 atom-shell，也就是后來的 Electron，是和 NW.js 類似的技術(shù)。它允許使用 Node.js（作為后端）和 Chromium（作為前端）來完成桌面 GUI 應用程序的開發(fā)。Chromium 提供了渲染頁面和響應用戶交互的能力，而 Node.js 提供了訪問本地文件系統(tǒng)和網(wǎng)絡(luò)的能力，也可以使用 NPM 上的幾十萬個第三方包。在此基礎(chǔ)之上，Electron 還提供了 Mac、Windows、Linux 三個平臺上的一些原生 API，例如全局快捷鍵、文件選擇框、托盤圖標和通知、剪貼板、菜單欄等。

Erich Gamma 老爺子設(shè)計的 Monaco／VS Code，同樣基于 Electron，但性能比 Atom 強多了。VS Code 會先啟動一個后臺進程，也就是 Electron 的主進程，它負責編輯器的生命周期管理、進程間通訊、UI 插件管理、升級和配置管理等。后臺進程會啟動一個（或多個）渲染進程，用于展示編輯器窗口，它負責編輯器的整個 UI 部分，包括組件、主題、布局管理等等。每個編輯器窗口都會啟動一個 Node.JS 子進程作為插件的宿主進程，在獨立進程里跑插件邏輯，然后通過事件或者回調(diào)的方式通知 Renderer 結(jié)果，避免了 Renderer 的渲染被插件中 JS 邏輯阻塞。

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

在第二階段里，我們可以看到 PC 桌面端以 Web 開發(fā)技術(shù)作為核心，以瀏覽器內(nèi)核作為跨平臺核心，最終將 Web 開發(fā)的代碼和瀏覽器內(nèi)核打包。這樣做的好處是前端開發(fā)相對簡單，相對于 C++ 等語言更為方便，另外從成本上考慮，也是極為劃算的。

如今，很多應用都開始基于 Electron 構(gòu)建，比如微信小程序 ide、微信 pc 版本等，另外非常令人激動的是，2018 年 10 月 18 日，迅雷論壇發(fā)文稱新版（從迅雷 X 10.1 版本開始）采用 Electron 軟件框架完全重寫了迅雷主界面。使用新框架的迅雷 X 可以完美支持 2K、4K 等高清顯示屏，界面中的文字渲染也更加清晰銳利。從技術(shù)層面來說，新框架的界面繪制、事件處理等方面比老框架更加靈活高效，因此界面的流暢度也顯著優(yōu)于老框架的迅雷。

第三階段：PWA 桌面版

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

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

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

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

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

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

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

小程序火爆

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

微信小程序的下一步計劃，支持 NPM、小程序云、可視化編程、支持分包等，聽起來很美好，但坑依然不少。小程序原生提供的 DSL 不夠好用，所以就有了上層開發(fā)框架或者腳手架來優(yōu)化開發(fā)效率，目前比較主流的有 3 個：

今年還冒出了微信小程序之外的頭條小程序、支付寶小程序、百度智能小程序等，未來還會有很多。同時，手機廠商大概是看到了小程序?qū)ζ鋺蒙痰甑耐{，小米、華為、OPPO、vivo 等九大國內(nèi)手機廠商聯(lián)手成立了“快應用聯(lián)盟”，基于 react-native 技術(shù)棧，整體也很不錯，尤其是天貓調(diào)用菜鳥裹裹的快應用，安卓下有非常好的體驗。相較而言，微信是基于 Webview 的，而快應用使用的是原生渲染方案，其他家也大抵如此。

其實 5G 時代很快就到了，大家可以暢想一下，在網(wǎng)速、內(nèi)存和 CPU 更高的情況下，5G 每秒最高下載速度高達 1.4G，秒下 PWA 或小程序應用，到底是離線，還是在線，猶未可知吧。

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

多端拉齊，并重用戶體驗

在 AI 時代，沒有“端”的支持可以么？明顯是不可以的。首先感謝蘋果，將用戶體驗提升到了前無古人的位置。移動互聯(lián)網(wǎng)興起后，PC Web 日漸沒落。我個人非常欣賞玉伯，在當年無線 ALL IN 戰(zhàn)略中，他還是選擇留下來繼續(xù)做 PC Web 的前端。不過，雖然很多公司的重點轉(zhuǎn)向無線，但 PC 業(yè)務也一直沒停，這是很多公司的現(xiàn)狀，也是客觀事實。那么，PC 端這樣的“老古董”的出路到底在哪里呢？

1. 我們可以利用 PC/H5 快速發(fā)版本的優(yōu)勢，快速驗證 AI 算法，繼而為移動端提供更好的模型和數(shù)據(jù)上的支撐。
2. 多端對齊，打好組合拳。既然不能在移動端有更大的突破，大家只能在細節(jié)上血拼。

大家的戰(zhàn)場已經(jīng)不是點了，已經(jīng)升級到打組合策略的階段了。未來一定是多端拉齊，并重用戶體驗的。

今天的大前端，除了 Web 外，還包括各種端，比如移動端、OTT，甚至是一些新的物聯(lián)網(wǎng)設(shè)備。我們有理由相信 Chrome OS 當年的遠見：“給我一個瀏覽器，我就能給你一個世界。”如果說的茍且一點：“給我一個 Webview，我就能給你一個世界。”

TypeScript

我之前就非常關(guān)注 TypeScript，但遲遲未下定決心在團隊內(nèi)落地。今年 1 月份北京 Node Party 上組了個局，和幾位嘉賓一起聊了一下，確認提效非常明顯，落地難度也不大，大家一致認為 2019 年 TypeScript 將有非常大的增長。本身前端團隊變大，規(guī)模化編程也必然依賴類型系統(tǒng)和面向?qū)ο蟮模瑥倪@點上看，TypeScript 也是完勝的。

這里再簡單介紹一下 TypeScript，它是有類型定義的 JavaScript 的超集，包括 ES5、ES5+ 和其他一些諸如反射、泛型、類型定義、命名空間等特征的集合，為了大規(guī)模 JavaScript 應用開發(fā)而生。復雜軟件需要用復雜的設(shè)計，面向?qū)ο缶褪且环N很好的設(shè)計方式，使用 TypeScript 的一大好處就是 TypeScript 提供了業(yè)界認可的類（ ES5+ 也支持）、泛型、封裝、接口面向?qū)ο笤O(shè)計能力，以提升 JavaScript 的面向?qū)ο笤O(shè)計能力。市面上的框架也對 TypeScript 提供了非常好的支持。

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

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

WebAssembly

WebAssembly 是一種新的字節(jié)碼格式，目前主流瀏覽器都已經(jīng)支持 WebAssembly。 和 JS 需要解釋執(zhí)行不同的是，WebAssembly 字節(jié)碼和底層機器碼很相似，可以快速裝載運行，因此性能相對于 JS 解釋執(zhí)行而言有了極大的提升。 也就是說 WebAssembly 并不是一門編程語言，而是一份字節(jié)碼標準，需要用高級編程語言編譯出字節(jié)碼放到 WebAssembly 虛擬機中才能運行， 瀏覽器廠商需要做的就是根據(jù) WebAssembly 規(guī)范實現(xiàn)虛擬機。這很像 Java 早年的 Applet，能夠讓其他語言運行在瀏覽器里。Applet 是一種 Java 程序，它可以運行在支持 Java 的 Web 瀏覽器內(nèi)。因為它有完整的 Java API 支持，所以 Applet 是一個全功能的 Java 應用程序。

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

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

AutoCAD 是由大量 C++ 代碼編寫的軟件，經(jīng)歷了非常多的技術(shù)變革，從桌面到移動端再到 web。之前，InfoQ 上有一個演講，題目是《AutoCAD & WebAssembly: Moving a 30 Year Code Base to the Web》，即通過 WebAssembly，讓很多年代久遠的 C++ 代碼在 Web 上可以運行，并且保證了執(zhí)行效率。

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

能夠讓如此龐大的項目跑在 Web 端，真的是非常了不起。通過 WebAssembly 技術(shù)，既能復用之前的 C++ 代碼，又能完成 Web 化，這也許就是所謂的兩全其美吧。

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

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

從 WebAssembly 的現(xiàn)狀來看，對于復雜計算耗時的部分采用其他語言實現(xiàn)，確實是比較好的一種方式。從趨勢上看，WebAssembly 讓所有語言都能跑在瀏覽器上，瀏覽器上有了 vm，瀏覽器不就是操作系統(tǒng)了嗎？

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

目前，V8 v6.9 (Chrome 69) 中的 Liftoff 已經(jīng)設(shè)置為默認工作狀態(tài)，也可以顯式地通過 --liftoff/--no-liftoff 或者 chrome://flags/#enable-webassembly-baseline 開關(guān)來控制。另外，Node.js v11 采用的 v8 引擎的 v7 版本，對 WebAssembly 支持更好，雖然這沒啥意義，但練手還是蠻好的。

移動端

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

除了不喜歡 Dart 外，F(xiàn)lutter 的其他方面都很好，在移動端現(xiàn)在強運營的背景下，支持熱更新是必備能力。

關(guān)于 Weex，一邊罵一邊用，很無奈的一種狀態(tài)。Weex 本身是好東西，捐給了 Apache，目前在孵化中，會有一個不錯的未來。但社區(qū)維護的非常差，問題 issue 不及時，文檔不更新。如果公司沒有架構(gòu)組，還是比較難搞定的。

不過也有很多不錯的案例，比如 2018 年優(yōu)酷雙十一活動就是使用 Weex 開發(fā)的，效果非常不錯。通過自建的可視化活動搭建平臺，能夠非常高效的完成開發(fā)，結(jié)合 App 內(nèi)的緩存，整體效果比 H5 好的多。

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

總結(jié)

總結(jié)一下，2018 年大前端的現(xiàn)象：

前端三大框架已趨于平穩(wěn)，標準化，向 Web Components 看齊。應用層面開始進入過渡封裝周邊的階段，很多細節(jié)都會埋在框架里。PWA 平穩(wěn)發(fā)展，兼容 4/5 瀏覽器，workbox 3 進一步簡化開發(fā)，另外 PWA 桌面版已經(jīng)開始興起，未來會更多。多端受到重視，不再只是 all in mobile。WebAssembly 讓更多語言可以運行在瀏覽器上，AutoCAD 的 web 版是非常好的例子。

強運營背景下，移動端以前端開發(fā)為主，已成定局。Flutter 局勢暫不好說，還在觀望中（主要是不喜歡 Dart）。TypeScript 落地很好，包容性更好：React 對.tsx 支持非常好，Vue 從 v2.5.0 之后對 ts 支持就非常好，Node.js（尤其是 Egg.js、midway）對 ts 支持也非常好。

5G 時代快來了，互聯(lián)網(wǎng)的長期在線情況有可能會被打破。本地設(shè)備即客戶端，可以大膽的想想。對前端來說，本地 web 服務，輔助日常開發(fā)，類似于 je 這樣的模塊會越來越多。

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

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

關(guān)于大前端的現(xiàn)狀和未來我就分享到這里，希望能對你有所幫助。