整合營銷服務商
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
篇文章主要向大家介紹一個全局命令行輔助開發工具liftoff，這個工具在npm托管平臺上周下載量還是很大的，但是在工作中卻很少看見有人使用！目前我知道在使用它的構建工具有gulp和fis3！
1、全局命令行（npm install xxx -g）調用項目目錄下安裝的本地包（npm install xxx）
目前很多的構建工具都把自己的功能分成了兩個部分：xxx-cli和xxx，比如gulp和webpack。
拿gulp舉例，在安裝完gulp-cli這個包后，是不能直接使用的，還需要在項目下安裝gulp這個包才行，工具作者的想法就是gulp-cli負責命令行參數的處理，本地的gulp包才負責具體構建邏輯的處理，即gulp-cli會加載本地的gulp包，然后將命令行參數傳給它！
一個全局命令行調用本地項目中安裝的包還是比較麻煩的，好在liftoff提供了這個能力（內部使用的是resolve這個包完成這個工作）。
2、加載配置
你會發現gulp、fis3、webpack等等一些構建工具都有一個本地的配置文件xxx.config.js，顯然在構建工具運行的時候需要讀取這個配置，那么liftoff也提供了這個能力，它還處理了一些特殊的情況，比如配置文件在祖先目錄下或者不在工程目錄下等特殊情況！
3、編譯特殊語言
有時用戶在寫配置文件時，不一定都會用javascript這個語言，如果用了其他語言開發了配置文件，node是無法加載的，所以需要先加載編譯腳本使其先被編譯，而liftoff就提供了這個能力，在使用特殊語言時可以先加載編譯腳本！
var Liftoff=require('liftoff'); //調用
var cli=new Liftoff(options);//實例化
cli.prepare(options, fn); //處理參數
cli.execute(options, fn); //執行回調函數
cli.launch(options, fn); //上面兩個方法的組合
假設我們現在提前為百度寫一個fis4（目前只有fis3），配置文件叫fis4-conf.js。
現在我們創建如下這樣的目錄：
圖1
index.js是我們命令行的邏輯，本地開發可以先不發包，
fis4-conf.js是配置文件，
fis4-local是本地需要安裝的包。
圖2
如圖2，在index.js中先實例化liftoff，傳入的對象的屬性在內部會被合并到cli這個實例對象上。這個配置中processTitle代表命令行運行后的進程名，moduleName代表這個命令行需要加載的本地的包名，configName代表本地配置的文件名！
如果上面三個屬性都沒傳，只有name屬性，processTitle和moduleName都會復用name的值，name再拼接一個‘file’字符串然后賦給configName。
extensions對象的key代表本地配置文件的后綴，value代表需要加載的編譯腳本，值可以是null、字符串、數組等，內部會將extensions這個字段用fined這個包來解析，所以配置規則可以參考這個包！
圖3
在圖3中我們調用了prepare方法，require參數可以是數組也可以是字符串（包名），代表需要提前加載運行的包；cwd默認是進程運行的目錄，這里通過cwd可以自定義root目錄；configPath參數可以重新定義配置文件的路徑。
現在我們打印一下后面回調函數的參數env，看看輸出什么？
圖4
如圖4，liftoff幫我們找到了本地配置文件的位置和本地需要加載的包fis4-local的位置，說到這里我想大家應該明白了，這些信息既然都拿到了后面怎么運行就看你自己了。
我們再聊聊如何用其他語言開發配置文件比如ts
我們現在建一個ts配置文件fis4-conf.ts，如圖5所示：
圖5
圖6
如圖6所示，extensions后綴修改成ts，值變成需要提前加載的編譯包，最后我們調用execute方法，這個方法不僅會加載extensions中注冊的包，還會加載require中注冊的包！
運行結果如下：
圖7
很好，符合預期。
如果大家不太清楚自己使用的語言對應的編譯腳本，可以使用interpret這個包，如下：
圖8
圖9
如圖9所示，interpret已經為我們整理好了各種后綴對應的編譯腳本的包！
這篇文章主要分析了liftoff解決加載本地包、加載項目配置文件以及如何加載其他語言的編譯腳本，可以把它當做我們開發命令行的輔助工具！另外既然我們了解了思路，其實我們也可以手寫這些邏輯，不一定要復用它，造輪子才可以更快的成長！
喜歡我的文章就關注我吧，后續會更多干貨輸出，讓我們一起學習，共同成長！（希望收藏之前大家關注一波-_-）
注風云之聲
提升思維層次
導讀
坐飛機不怕暈機，最怕機暈。
撰文 七君
在獲得了兩項奧斯卡提名的2012年的電影《迫降航班》中，出現了超出常識的一幕：機長讓飛機上下倒著飛。
飛機顛倒飛行真的科學嗎？
若是按照許多教科書的理論，這是不可能的。
可是這些教科書中的理論是錯的，美國國家航空航天局（NASA）還專門制作了一個網站來批判這些理論。
這種盛行的錯誤理論是，機翼上部比下部更長，使得空氣分子在上部的移動距離更長，因此速度必須更大才能和下部的空氣分子匯合。這種理論接著解釋，根據伯努利定律，速度增加時氣壓減少，因此機翼上部的氣壓比下部低，機翼就被往上推了。
圖片來源：wikipedia
NASA 介紹，事實上上下對稱的機翼，甚至下部更彎曲更長的機翼也能產生升力；這種理論也無法解釋空戰和飛行特技中飛機顛倒著飛的情況。
美國空軍雷鳥飛行表演隊在2012年的 北極雷霆航空展上表演倒飛。圖片來源：wikicommons
此外，雖然機翼上方空氣的流速比下方更大，但是上部的速度快到無法和下部的空氣在機翼末端匯合，因此這個理論是有問題的。
不過，機翼上部的氣壓確實小于下部，這一點真實不虛。
那么到底是什么讓飛機飛翔呢？
NASA指出，升力的產生存在巨大的爭議，許多教科書的解釋是錯的。圖片來源：www.grc.nasa.gov/WWW/k-12/airplane/lift1.html
NASA 介紹，關于飛機如何獲得升力存在許多理論，也存在很大爭議，尚未達成統一，但現在能確定的是，物體獲得升力的過程很復雜，迎角和機翼的形態和升力密切相關。
機翼的形態比較好理解，我們平時看到的機翼都是上鼓下平。
迎角指的是機翼迎風的傾斜角度。事實上在70多年前，人類發現了迎角和升力之間的重要關系：對于特定的機翼來說，在一定范圍內，迎角越大，升力就越大。
上鼓下平的機翼（正彎度機翼）和不同的迎角。圖片來源：FAA
機翼的迎角在5-6度時獲得的升力遠超1-2度時的情況。在起飛前的一瞬，飛行員會讓飛機昂頭，這就是為了增加迎角，從而增加升力的操作。即使是完全扁平的機翼在調整了迎角之后也能起飛，放風箏就是這個原理。
如果把各種機翼設計的迎角和機翼的性能——升力系數（升力系數和升力成正比，一般來說升力系數越大越好）作圖，那么我們就會發現，不同機翼的數據構成了一條直線。
在一定范圍內，迎角（橫坐標）越大，升力系數（縱坐標）越大。圖片來源：wikipedia
這個知識最初來自1945年NASA的前身美國國家航空咨詢委員會 (NACA)公布的一份關于機翼的資料——NACA Technical Report 824。這份報告里面包含著許多機翼在風洞中的測試數據，它在日后成了各種機翼設計參考書的基礎。
有趣的是，如果把機翼上下顛倒再測試，升力的數據和迎角之間的關系也是類似的。
正彎度（最粗的藍線），零彎度（上下對稱）和負彎度機翼（最細的藍線）的升力系數都隨著迎角的增加而增加。圖片來源：Gudmundsson, Snorri. General aviation aircraft design: Applied Methods and Procedures. Butterworth-Heinemann, 2013.
實際上，把常見機翼上彎下平的設計倒轉過來的翼型叫做負彎度（negative camber），只要迎角夠大，負彎度的機翼也能飛起來。只不過在同樣的迎角下，它們獲得的升力要少一些，也就是說飛得要吃力些。
我們還可以看荷蘭特文特大學用模型飛機做的演示。
如果飛機能飛起，那么飛機會帶動桿子向上移動。大家可以看到，倒著飛的時候，飛機模型在風洞里也能升起，只不過效率降低了。
在飛行史上，首次讓飛機倒著飛的人是法國傳奇飛行員 Alphonse Pégoud。1913年，他駕駛著一架 Blériot 型號的單翼機，展示了倒著飛的特技。
Blériot 型號的單翼機。圖片來源：wikipedia
1914年，一位德國勇士也學會了倒著飛的特技。這個叫做 Gustav Tweer的小伙子更野，他不但讓一架Grade型號的單翼機倒著飛，還倒著落地。
1914年，經常倒著飛的德國飛行員 Gustav Tweer 讓飛機倒著著陸。
圖片來源：flying magazine
現代意義上的客機也曾有倒著飛的記錄。
在2000年1月31日的阿拉斯加航空261號班機空難中，由于機械故障，一架MD-83型號的客機失控，頭向下俯沖了一段時間。后來機組人員努力使機頭保持水平，在空中上下顛倒地飛了大約1分鐘。但不幸的是，此時飛機已經非常接近太平洋，最終墜落在了海中。《迫降航班》中客機倒飛的情節也來源于此。
雖然機翼上下顛倒并不會使機翼失去升力，不過現代客機倒飛時會面臨其他問題。
其中一個大問題就是供油。普通飛機的油箱中為引擎供油的管子開口貼近油箱底部，而且無法移動。如果飛機倒著飛，油管的相對位置就會變成油箱頂部，那樣就無法為引擎提供燃料了。
而能倒著飛的特技飛機的供油管巧妙地解決了這個問題。這類飛機常會采用能夠活動的管子 flop tube，它的尾端比較重，而且能夠活動。在飛機倒轉時，油管也會跟著翻身，繼續為引擎供油。
特技飛機的另外一種策略是使用特殊的油箱，如位于機翼下方的 header tank。一些特技飛機，比如 Super Decathlon 型號的飛機的油箱在飛機上方，飛機正飛的時候，重力使燃油向下流入燃油泵。但是在機翼下方還有一個油箱 header tank，它也和燃油泵相連。在飛機倒轉時，這個油箱就到了機翼上方，可以利用重力為引擎供油。
這些技術就是特技飛機可以在空中玩蛇皮走位，但客機不行的小秘密了。
坐飛機不怕暈機，最怕機暈。
擴展閱讀：
按照概率學原理，你這牌一看就胡不了 | 把科學帶回家
垃圾不分類隨便扔的人，是在制造“世紀之毒” ｜把科學帶回家
不懂物理的裁判造成世界杯經典冤案，50年前物理學家就發現了球的奇特運動 | 把科學帶回家
長大后吸掉了自己的腦子，這種動物曾被主流教材視為人類的原始祖先 | 把科學帶回家
者｜狼叔
編輯｜覃云
你好，我是阿里巴巴前端技術專家狼叔，今天想跟你分享 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 等。
另外，在 create-react-app（cra）項目里使用的是 react-scripts 作為啟動腳本，它和 egg-scripts 類似，也是通過約定，隱藏具體實現細節，讓開發者不需要關注構建。在未來，類似的封裝還會有更多的封裝，并且更偏于應用層面。
PWA 和 native app（移動應用）的核心區別在于以下幾點：
現在 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 端這樣的“老古董”的出路到底在哪里呢？
大家的戰場已經不是點了，已經升級到打組合策略的階段了。未來一定是多端拉齊，并重用戶體驗的。
今天的大前端，除了 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 真的能夠替人寫代碼，能應變的人自然也是不怕的。
關于大前端的現狀和未來我就分享到這里，希望能對你有所幫助。
*請認真填寫需求信息，我們會在24小時內與您取得聯系。
