《Babel笔记》的实验室
本项目用于测试Babel各种配置的运行结果，同时结合webpack测试一下输出的结果，下面就几个总结一下：
往往全局引入一次babel-polyfill，就可以放心的使用类似于Promise、Array.find或者是[].find()之类的全局对象及其扩展方法，同时，避免一些老的浏览器不支持Promise等对象所带来的麻烦，不过也有2点需要注意：
- babel-polyfill文件很大，尤其是在移动端做性能优化时，需要权衡一下；
- babel-polyfill是全局替换，如果你做了很多模块化的工作，可能会导致一些代码冗余或者冲突；
本实验主要是测试一下如果在.babelrc文件中配置了"plugins": ["transform-runtime"]与不配置的区别，顺便得出以下结论：
比如，我需要Promise，那么还需不需要在目标文件中加入import Promise from 'babel-runtime/core-js/promise';
A: 不需要手动引入了，并且该插件还将你需要的
babel-runtime/*单独抽离了出来，从而减少冗余的转换代码，在项目模块比较多的时候，特别有优势。
对比module-A、module-B2个文件不同配置下的Babel处理结果，发现启用了babel-runtime的代码处理是直接引用babel-runtime/*下已经抽离的模块，例如createClass、classCallCheck等, 而直接使用Babel转码，会往目标文件中单独注入这些模块的代码（代码实现略有不同，不过目标是一直的）。
另外，经过webpack处理以后，竟然神奇的发现，与我预期的babel-runtime处理的结果文件体积更小正好相反：
使用
babel-runtime与webpack处理的结果
未使用
babel-runtime，直接使用webpack处理的结果
单从的modules数量来看，使用babel-runtime的处理尽然有
- 102 hidden modules
而未使用babel-runtime的处理结果只有
- 65 hidden modules
并且文件大小也近小了1/3。
但是仔细看，你会发现在未使用babel-runtime的use-import.bundle.js中，同样的_classCallCheck出现了2次，但是在使用了babel-runtime的use-import.bundle.js中，都是引用自一个地方，可以想象，如果有几百个模块都用到了Class，那将有多少的冗余代码。
A：如果你仅仅是几个文件，用到
Class之类的地方不是很多，那么或许不使用babel-runtime或许会有更好的处理效果；
但是如果你是做一个项目，包含了很多模块，那么还是建议使用babel-runtime会更加有优势；
在做实验的时候，也用到了部分webpack与babel-loader的配置，发现了几个有趣的地方，未做深入，仅简单记录一下：
开启
exclude: /(node_modules|bower_components)/，不对这2个文件夹中的文件做Babel处理，结果dist.bundle.js文件体积为251 kB；
未开启
exclude产出的dist.bundle.js文件体积为227 kB；
那么，简单的认为使用Babel对babel-polyfill处理一下就能减少近24 kB的文件大小，牺牲的不过是一些编译的时间，在我看来，这个还是值得的。
Tip：这里的处理为使用
babel-runtime，但是看使用babel-runtime的几个处理结果来看，也是一样的。