我们为什么会使用babel？因为我们会使用很多es的新语法。但浏览器的支持却还不完善。所以我们只能使用babel编译器来帮助我们。
如果我们还使用了webpack的话，我们会在webpack中增加babel-loader
{
test: /\.js$/,
loader: 'babel-loader',
include: [resolve('src'), resolve('test')]
},
在babel5的时代，babel属于全家桶型，只要安装babel就会安装babel相关的所有工具，
即装即用。
但是到了babel6，具体有以下几点变更：
移除babel全家桶安装，拆分为单独模块，例如：babel-core、babel-cli、babel-node、babel-polyfill等；
使用babel的会自动识别.babelrc文件。
该文件用来设置转码规则和插件，基本格式如下。
{
"presets": [], // 设定转码规则
"plugins": [], //
}
plugin:，插件，通过配置不同的插件才能告诉babel，我们的代码中有哪些是需要转译的。
preset：babel5会默认转译ES6和jsx语法，babel6转译的语法都要在perset中配置，preset简单说就是一系列plugin包的使用。
为什么我们经常会看到Stage 2这种插件？
ES即ECMAScrip。被纳入到ES标准的语法必须要经过如下五个阶段:
Stage 0: strawman
Stage 1: proposal
Stage 2: draft - 必须包含2个实验性的具体实现，其中一个可以是用转译器实现的，例如Babel。
Stage 3: candidate - 至少要有2个符合规范的具体实现。
Stage 4: finished
除了已经正式纳入规范 (ES2015/6/7) 的特性，还有许多处于不同讨论阶段的特性提案 (stage 1/2/3/4)。这些讨论中的特性严格来说还不算是标准，尤其是 stage 1/2 的特性，完全有可能被改动甚至是撤销提案。因此从 babel 的角度来说，显然不能够默认启用这些特性，而需要有可配置的选项让用户自行衡量风险，决定是否使用。
那么我们如何判断我们需要使用的stage是哪一个呢？
在TC39的提案中，有对应的一个详细的列表表明哪种特性处于哪个阶段：处于哪个阶段
所以我们经常会看到"stage-2"。
transform-runtime VS babel-polyfill
为什么需要 babel-polyfill？因为babel的转译只是语法层次的转译，例如箭头函数、解构赋值、class，对一些新增api以及全局函数（例如：Promise）无法进行转译，这个时候就需要在代码中引入babel-polyfill，让代码完美支持ES6+环境。但很多时候我们并不会使用所有ES6+语法，全局添加所有垫片肯定会让我们的代码量上升，之后会介绍其他添加垫片的方式。
那我们可以用到那个语法或者api增加哪个对应的插件呀。
{
"plugins": [
"transform-es2015-arrow-functions", //转译箭头函数
"transform-es2015-classes", //转译class语法
"transform-es2015-spread", //转译数组解构
"transform-es2015-for-of" //转译for-of
]
}
这样有个问题。这种通过transform添加的polyfill只会引入到当前模块中，试想实际开发中存在多个模块使用同一个api，每个模块都引入相同的polyfill，大量重复的代码出现在项目中，这肯定是一种灾难。另外一个个的引入需要polyfill的transform挺麻烦的，而且不能保证手动引入的transform一定正确。所以我们使用transform-runtime
比较transform-runtime与babel-polyfill引入垫片的差异：
- 使用runtime是按需引入，需要用到哪些polyfill，runtime就自动帮你引入哪些，不需要再手动一个个的去配置plugins，只是引入的polyfill不是全局性的，有些局限性。而且runtime引入的polyfill不会改写一些实例方法，比如Object和Array原型链上的方法，像前面提到的Array.protype.includes。
- babel-polyfill就能解决runtime的那些问题，它的垫片是全局的，而且全能，基本上ES6中要用到的polyfill在babel-polyfill中都有，它提供了一个完整的ES6+的环境。babel官方建议只要不在意babel-polyfill的体积，最好进行全局引入，因为这是最稳妥的方式。
- 一般的建议是开发一些框架或者库的时候使用不会污染全局作用域的babel-runtime，而开发web应用的时候可以全局引入babel-polyfill避免一些不必要的错误，而且大型web应用中全局引入babel-polyfill可能还会减少你打包后的文件体积（相比起各个模块引入重复的polyfill来说）。
不过目前官方推荐babel-preset-env
这款preset能灵活决定加载哪些插件和polyfill。这样，如果我们支持的浏览器较新，那么很多插件根本就不需要用到，既能保证浏览器兼容性，也能保证最佳的编译速度和最小的 Polyfill 体积。
babel到底该如何配置
babel为什么要通过插件编译
为什么vue-cli中babel的配置即使用babel-preset-env又使用transform-runtime
babel-preset-env是根据浏览器判断需要加载的插件和polyfill而不是直接加载。transform-runtime和babel-polyfill都是引入polyfill。没有polyfill的话env也没的加载呀。
在babel-preset-env@2.x中已经完全可以用useBuiltIns: usage来达到按需引入的目的，也就是说不再需要transform-runtime了，并且也不再需要在代码中手动引入babel-polyfill了（但是还需要安装，因为编译后的代码依赖了它），Babel 会在你使用到 ES2015+ 新特性时，自动添加 babel-polyfill 的引用，并且是 partial 级别的引用。
请注意： usage 的行为类似 babel-transform-runtime，不会造成全局污染，因此也会不会对类似 Array.prototype.includes() 进行 polyfill。
