資訊專欄INFORMATION COLUMN
摘要：換言之，用的代碼取代。模塊在頂層作用域中創(chuàng)建聲明變量的行為有別于腳本。但現(xiàn)在是可以部署的，所以是時候去改變了。通過發(fā)布，我們?yōu)殚_發(fā)人員提供了一種選擇，并最終惠及每個人。編寫代碼對開發(fā)者來說是一個勝利，部署代碼對用戶來說是一個勝利。
原文鏈接
與我交流過的絕大多數(shù)web開發(fā)者，都喜歡使用所有新的語法特性（如async/await，類，箭頭函數(shù)等）。盡管所有現(xiàn)代瀏覽器都支持以上的語法，多部分開發(fā)者仍然會轉(zhuǎn)譯到ES5并且加上polyfill以便支持哪一小部分仍舊使用老版本瀏覽器的用戶。
這...有點糟。在理想的的世界中，是沒有不必要的代碼！
新版本的JS和DOM接口能讓我們選擇性地加載polyfill，因為在運行時，我們可以檢測瀏覽器對新特性的支持情況。但是新的JS語法有一點不好，因為無法識別的語法都會造成解析錯誤，導(dǎo)致沒有代碼會被執(zhí)行。
雖然現(xiàn)在并沒有對feature-detecting這個語法的好的解決方案，但我們確實有一個方法能做到ES2015語法支持的檢測。
這就是
小貼士：可惡的Safari 10并不支持nomodule屬性，不過你可以在HTML前部引入safari-nomodule.js來解決這一問題。（好在，在Safari 11種他們解決了這個問題，我到都拔出來了）
重要的思考
！
這多數(shù)情況下，這個方法“能用”。但是在使用這一策略前，我們需要了解模塊加載的一些細(xì)節(jié)。
模塊會像
即便經(jīng)過Gzip傳統(tǒng)ES5版本也是ES2015+版本體積的兩倍。
大體積文件不盡更耗費時間去加載，同時，也需要更長時間解析與執(zhí)行。這兩個版本的解析／執(zhí)行時間依舊是兩倍的關(guān)系。（這個測試我試用了webpagetest.org提供的 Moto G4）
雖然這些獨立的文件不大，解析/執(zhí)行的時間也不是特別長，但這僅僅是個博客。如果是外頭那些龐然大物，ES2015+你絕對值得擁有！
一項來之HTTPArchive數(shù)據(jù)的統(tǒng)計顯示。Alexa排名前列的網(wǎng)站中有85181在他們的項目中使用了babel-polyfill, core-js, 或是regenerator-runtime。6個月前這個數(shù)字是34588!
現(xiàn)實就是轉(zhuǎn)譯以及使用polyfill正迅速成為新的標(biāo)準(zhǔn)。不幸的事，大部分用戶正因此犧牲了流量來下載這些本來可以更小的文件。
是時候，祭出ES2015了現(xiàn)在的問題就是開發(fā)者并沒有發(fā)布ES2015+版本的代碼，而是發(fā)布了轉(zhuǎn)譯后的ES5版本。
但現(xiàn)在ES2015+是可以部署的，所以是時候去改變了。
我完全明白，這會帶來一些陣痛。 如今大多數(shù)構(gòu)建工具發(fā)布的文檔，都推薦ES5的配置。 這意味著，如果模塊作者開始向npm發(fā)布ES2015 +源代碼，他們可能會破壞一些用戶的構(gòu)建，這將會造成混亂。
問題是大多數(shù)使用Babel的開發(fā)人員將它配置為不在node_modules中傳輸任何內(nèi)容，但是如果模塊是使用ES2015 +源代碼發(fā)布的，則這是一個問題。 幸運的是修復(fù)很簡單。 您只需從構(gòu)建配置中刪除node_modules排除：
rules: [
{
test: /.js$/,
exclude: /node_modules/, // 移除這行
use: {
loader: "babel-loader",
options: {
presets: ["env"]
}
}
}
]
弊端就是，babel這樣的工具不僅僅需要本地依賴關(guān)系，在執(zhí)行時還需要在node_modules中傳遞這種關(guān)系。這樣構(gòu)件會變慢。不過這一問題可以在持續(xù)化的本地緩存工具上得到解決。
縱使前途坎坷，我們也因該為提升用戶體驗大步向前。通過發(fā)布ES2015，我們?yōu)殚_發(fā)人員提供了一種選擇，并最終惠及每個人。
結(jié)論