大家好，我是阿里巴巴前端技術專家狼叔，今天想跟你們分享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 (
<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已經思考的相對全面，從技術選型、構建到多端輸出、性能優化、發佈等方面進行了拆分，使得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 的超集，包括 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 & 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真的能夠替人寫代碼，能應變的人自然也是不怕的。
關於大前端的現狀和未來我就分享到這裏，希望能對你有所幫助。
更多內容，請關注前端之巔。
