我其實特別反感很多人說“前端娛樂圈”這種話，誠然，爆發式增長必然會帶來焦點，但也不必過度解讀，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 (
<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 的人已經不多了。框架一旦穩定，就會有大量培訓跟進，導致規模化開發。這是把雙刃劍，能滿足企業開發和招人的問題，但也給創新探索領域上了枷鎖。
框架和工程化基本探索穩定后，大家就開始思考如何更好的用，更簡單的用。目前，各家大廠都在前端技術棧思考如何選型和降低成本，統一技術棧。
舉個例子 Umi，Umi 就是一套零配置（約定高于配制），按最佳實踐進行開發的，開箱即用的前端框架: React 全家桶 + dva + jest + antd (mobile) + less + eslint。如下圖所示：
零配置就是默認選型都給你做好了。
開箱即用就是技術棧都固化了。
約定大于配置，開發模式也固化好了。
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 和 native app（移動應用）的核心區別在于以下幾點：
安裝：PWA 是一個不需要下載安裝即可使用的應用。
緩存使用：native app 主要是對 sqlite 緩存，以及文件讀寫操作，而 PWA
對緩存數據庫操作支持的非常好，足以應對各種場景。
基本能力補齊，比如推送。
現在 PWA 已經支持的很好了，唯一麻煩的是緩存策略和發版比較麻煩，應用輕量化的趨勢已經很明朗了。下面講一下 PWA 的一些關鍵點。
Workbox 是 GoogleChrome 團隊推出的一套 Web App 靜態資源和請求結果本地存儲的解決方案，該解決方案包含一些 JS 庫和構建工具，Workbox 背后則是 Service Worker 和 Cache API 等技術和標準在驅動。在 Workbox 之前，GoogleChrome 團隊較早時間推出過 sw-precache 和 sw-toolbox 庫，但罵聲很多，直到 Workbox 才真正誕生了能方便統一的處理離線能力的更完美的方案。
Workbox 現在已經發布到了 3.0 版本，不管你的站點是用何種方式構建的，它都可以為你的站點提供離線訪問能力，幾乎不用考慮太多的具體實現，只用做一些配置就可以。就算你不考慮離線能力，它也能讓你的站點訪問速度更快。
縱觀 PC 桌面端的發展過程，早期 Delphi/VB/VF/VC 等構建起的 c/s 時代，即使到今天依然有很大的量。最近兩年，隨著 Atom/VSCode 的火爆，帶動了 node webkit 相關模塊的爆發，比如 NW.js 和 Electron 等。通過 Web 技術來構建 pc client，確實是省時省力，用戶體驗也非常好，比如釘釘客戶端、石墨文檔客戶端等，最主要的是可以統一技術棧，比如某些算法，用 JS 寫一次，之后可以到前端、node、pc client 等多處復用。當然更好的是使用 Web 技術進行開發，不需要加殼打包，PWA 桌面版就是這樣的技術。
接下來就具體聊一下桌面端的 3 個發展階段。
早年的 VB/VF/VC/Delphi 等原生開發方式，到后來出現 QT 類的跨平臺軟件，但依然可以理解成是原生開發。
谷歌于 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，例如全局快捷鍵、文件選擇框、托盤圖標和通知、剪貼板、菜單欄等。
演進過程：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 等高清顯示屏，界面中的文字渲染也更加清晰銳利。從技術層面來說，新框架的界面繪制、事件處理等方面比老框架更加靈活高效，因此界面的流暢度也顯著優于老框架的迅雷。
王國維在《人間詞話》中提出“隔與不隔”這一文學命題，這個問題在開發領域也是存在的。明明是 Web 開發的，為什么還要打包加殼呢？除了體積非常大以外，使用安裝也極為麻煩。
Spotify 的 PWA 桌面版應用體驗是非常好的，在 mac 上絲般順滑。
PWA 必然會改變前端與移動端之間的格局，再加之 AOT(ahead-of-time) 與 WebAssembly 為 JS 帶來的性能上的突破，JavaScript 將撼動所有領域，從移動端（PWA）到桌面應用、物聯網、VR、AR、游戲乃至人工智能等等。
Google 接下來會大力推進 PWA 的桌面版，再加上 win10 和 Chrome 加持，Web 應用無需加殼就能達到近乎原生的體驗，前端的領域再一次被拓寬，未來真的可以大膽的想想。
很多人問 PWA 在國內為什么感覺不火，原因很簡單，PWA 在弱網環境下表現極好，但中國的網絡是全球最好的，所以 PWA 其實沒有給我們帶來那么大的收益。不過當做一個補位方案也挺好的，畢竟 2G/3G 還有點量，另外在服務器渲染 SSR 上，PWA 也能夠起到很好的效果。
如果說和 PWA 比較像的，大概就是小程序了，小程序也可以說是今年最火的技術。
其實 5G 時代很快就到了，大家可以暢想一下，在網速、內存和 CPU 更高的情況下，5G 每秒最高下載速度高達 1.4G，秒下 PWA 或小程序應用，到底是離線，還是在線，猶未可知吧。
前端能講的東西實在太多了，但受限于篇幅，本文只能先簡單跟你分享 React/Vue/Angular 三大框架標準化、應用層封裝進入爆發期、PWA 進入穩定期、小程序火爆等方面的內容。下一篇文章中，我將繼續跟你聊聊移動端局面、多端拉齊的必然性等內容，以及 2019 年不可忽視的 TypeScript 和 WebAssembly 這兩大技術，歡迎繼續關注，也歡迎留言與我多多交流。
在 AI 時代，沒有“端”的支持可以么？明顯是不可以的。首先感謝蘋果，將用戶體驗提升到了前無古人的位置。移動互聯網興起后，PC Web 日漸沒落。我個人非常欣賞玉伯，在當年無線 ALL IN 戰略中，他還是選擇留下來繼續做 PC Web 的前端。不過，雖然很多公司的重點轉向無線，但 PC 業務也一直沒停，這是很多公司的現狀，也是客觀事實。那么，PC 端這樣的“老古董”的出路到底在哪里呢？
我們可以利用 PC/H5 快速發版本的優勢，快速驗證 AI 算法，繼而為移動端提供更好的模型和數據上的支撐。
多端對齊，打好組合拳。既然不能在移動端有更大的突破，大家只能在細節上血拼。
大家的戰場已經不是點了，已經升級到打組合策略的階段了。未來一定是多端拉齊，并重用戶體驗的。
今天的大前端，除了 Web 外，還包括各種端，比如移動端、OTT，甚至是一些新的物聯網設備。我們有理由相信 Chrome OS 當年的遠見：“給我一個瀏覽器，我就能給你一個世界。”如果說的茍且一點：“給我一個 Webview，我就能給你一個世界。”
我之前就非常關注 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。 和 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 在全民直播里對直播編解碼方面的應用，效果也非常不錯。
另外，許式偉在 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 好的多。
前端三大框架已趨于平穩，標準化，向 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 真的能夠替人寫代碼，能應變的人自然也是不怕的。
關于大前端的現狀和未來我就分享到這里，希望能對你有所幫助。
