生產環境部署es6代碼

時間流轉，來到了9102年的末尾，距離es6正式發佈已通過去了4年半。在前端發展的時間長河中，咱們送別了YUI，ie（也許），jQuery，如今，是時候送別es5了。html

收益在哪

程序員在進行技術決策的時候，一般的目的是爲了~~kpi~~，~~升值加薪~~，~~這個技術很流行~~，不，固然是爲了對業務產生價值。前端

不難發現，直接部署es6代碼能夠帶來的好處包括：vue

代碼體積減少
性能提高
縮短構建時間

代碼體積減少

首先，es6帶來了新的語法和特性，這可讓代碼更簡潔，使得代碼量減小。其次，babel轉譯以後，會產生一些helper，引入一些polyfill，並且有一些語法特性沒法在運行時進行處理，必須在轉譯過程當中修改源代碼，這也會致使代碼量增長。固然，部署es6代碼也須要babel轉譯一部分更新的語法，並非說徹底不使用babel。node

一個Google工程師的試驗結果，es6代碼的bundle size比es5代碼減小了50%。而我本身的實踐的結果沒有這麼誇張，是25%左右。git

version	bundle size	Gzipped
es5	221kb	39kb
es6	170kb	29kb

之因此我和他的測試結果差別較大，是由於最終的結果跟每一個人的代碼風格和代碼內容有很大的關係。我用來進行測試的代碼是一個線上項目的代碼，我我的的代碼風格是大量使用es6/7/8語法，不過項目自己大量是在寫業務邏輯，而且項目使用了Vue，其實不少js代碼是模板編譯以後生成的渲染函數。程序員

因此，大概的結論是es6的代碼會比es5的代碼體積減小15% ~ 50%，具體能減小多少，取決於代碼風格以及代碼內容。代碼風格越現代，代碼中"生成的代碼"越少，收益越高。es6

性能提高

es6代碼相對於es5代碼，性能更高的緣由我認爲有2個github

代碼量減小帶來的解析時間減小，這個正比於代碼體積的減小
運行性能的提升

對於第一點，瀏覽器解析代碼時間的減小應該佔比較小，經過chrome的Performance面板能夠看到，解析一個200kb的js文件Compile Script耗時爲10ms（測試機器爲臺式機，i7/16G）。web

對於第二點，運行時性能。在es6剛剛發佈的時候，不少新特性的性能是比較低的，由於js引擎沒有足夠的時間去進行優化，相比較而言，es5以及更老的代碼通過了瀏覽器的長時間優化，在es6剛出來的時候，很對人也對es6的性能有很大的擔心。chrome

Github上有一個倉庫，專門對es6和es5進行了性能對比。

從對比結果能夠看出來，在chrome 72版本上，es6代碼的性能優於babel轉譯成的es5代碼，和手寫的es5代碼比起來各有千秋，基本算是55開。

並且，瀏覽器對於es6的性能優化是持續性的，最近V8就會由於React hooks而改進數組解構的性能。

針對運行時的es6代碼和es5代碼的性能對比，我也用一個線上項目進行了實驗。實驗方式以下

利用performance API在打包後的app.js文件開頭記下時間戳，在js文件末尾減去開始的時間，獲得一個時間，衆所周知，打包以後的app.js是一個當即執行函數，因此這個時間包含了app.js文件中部分代碼的運行時間
利用chrome 的Performance面板，能夠直接獲得一段js的執行時間Evaluate Script

實驗結果以下（20次的平均值）

version	記錄的運行時間	Performance面板的Evaluate Script
es5	258.88ms	295.29ms
es6	206.28ms	241.59ms

測試條件下，es6的代碼取得了20%左右的運行性能提高

風險在哪兒

js的運行環境很是複雜，桌面端、移動端、各類小程序、各類webview、node.js，可否部署es6代碼只能依靠本身判斷。

就我我的的經驗而言，大部分的中後臺項目都具有直接部署es6代碼的條件，並且咱們在具體的實施中確定會有降級方案，讓不支持es6的狀況下運行es5的代碼。

如何實施

Vue用戶能夠經過Vue cli的 --modern直接開啓現代模式

非Vue使用者，能夠經過這篇文章提到的方案來進行。大概就是利用script標籤的type=module做爲瀏覽器是否全面支持es6的檢測，並經過type=nomodule來進行降級處理。

// 不支持module的瀏覽器，下載但不會執行
<script type="module" src="es6.js"></script>

// 支持module的瀏覽器，不會下載
<script nomodule src="es5.js"></script>
複製代碼

一個須要注意的點是safari 10不支持nomodule，因此須要針對它解決重複下載並執行的問題。(ps: safari瀏覽器是新時代的毒瘤)

雖然，一個降級的方案能夠保證咱們的代碼能夠在只支持es5的瀏覽器上也能夠執行，可是同時這些老的瀏覽器會下載2份代碼，帶來的損失很是大，由於老設備一般也意味着低性能和低網速，它們更不能承受性能損失。因此我認爲，若是你的業務須要兼容es5的用戶達到了20%以上，我就不贊同採用這個方案。

若是能夠肯定徹底不須要兼容es5的用戶，能夠直接修改browserlist到全面支持es6的瀏覽器版本，而且不用考慮降級方案，此時還會帶來構建速度提高這一額外的好處。

browserslist示例

Chrome >= 60
Safari >= 10.1
iOS >= 10.3
Firefox >= 54
Edge >= 15
複製代碼

結語

時間帶走一切，es5也不例外。