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