摘要：换言之，用的代码取代。模块在顶层作用域中创建声明变量的行为有别于脚本。但现在是可以部署的，所以是时候去改变了。通过发布，我们为开发人员提供了一种选择，并最终惠及每个人。编写代码对开发者来说是一个胜利，部署代码对用户来说是一个胜利。
原文链接
与我交流过的绝大多数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，我们为开发人员提供了一种选择，并最终惠及每个人。
结论