最近项目中的一个模块正式引入的ES6，由于是引入新技术，也遇到了一些问题，下面分享下整个引入流程
为什么要引入ES6
最近在看一些前端解决方案的文章，ES6越来越多的出现在前端方案中。
ES6由于浏览器不支持，在使用上也是和CoffeeScript和TypeScript一样，都需要compile-to-JS。
理由一：
符合未来趋势，angular2就是使用TypeScript实现；
react native 也是可以直接使用es6的语法；
理由二：
提高开发效率（待考证）；
理由三：
减少代码量、提高可读性等
但我觉得不仅仅如此，应该会有更多优势。所以需要亲自验证。
引入前考虑最多的事情
从个人的角度，趋势这个东西说不准，减少代码量、提高可读性等这些其实都可以通过规范来完成。
我个人最看重的是效率这块，是否能够真正的提高团队开发效率。
另外在一片文章中看到说facebook.com 都使用了ES6 + babel complile，我心里也安稳了一些。
考虑的第二点就是是否会给整个系统引入技术债务，由于这个是新技术的引入，和之前框架没有任何重叠，而且引入也是选择性的（提供一种可用的环境）。如果未来有较大的升级，我们可以修改compile-to-JS做适配和转换。
最后一个问题是我们项目使用的不是grunt这种，有直接的解决方案，引入可能会有风险。不过庆幸的是，我们发现我们使用的edp已经支持了。其实我们开始已经想好了如果不支持，自己会扩展一些插件去支持。
技术方案
ES6 + babel
需要解决的问题
- 开发环境下的浏览器不支持ES6？
- 使用babel转换的代码，调试不方便？
- 线上环境的代码打包编译怎么处理？
- ES6的新特性哪些适合使用？
- ES6的新特性是否通过babel转换后还有兼容问题？
- 开发效率是否会有提高？
- 编译器高亮支持？
下面挨个解决问题
想到一句话
你可以坐以待毙，也可以立刻动手解决问题，解决一个再解决一个，解决了所有问题，你就活下来可以回家了
来自《火星救援》
开发环境下的浏览器不支持ES6？
这个容易，使用babel。
使用babel转换的代码，调试不方便？
确定了sourceMap的方式解决，但是开始没有认真看babel文档，绕了个圈子，最后发现babel有个属性
1 | sourceMaps：both |
传入这个参数sourceMaps传入表示启用；
filename是编译前对应的文件,这里必须给一个和处理的文件名不一样的
1 | babel.transform(code, options) |
线上环境的代码打包编译怎么处理？
在构建的流程中，加入一个babel-processor的流程即可，加入的时机需要是在模块压缩合并前，其实就是越早越好。
ES6的新特性哪些适合使用？
我们参考
使用ES6进行开发的思考
arrows ★★★
classes ★★★
enhanced object literals ★★★
template strings ★★★
destructuring ★★
default + rest + spread ★★★
let + const ★★★
iterators + for..of ★★
generators ★
unicode ☆
modules ★★
module loaders ☆
map + set + weakmap + weakset ★★
proxies ☆
symbols ★
subclassable built-ins ☆
promises ★★★
math + number + string + array + object APIs ★★★
binary and octal literals ★
reflect api ☆
tail calls ★★
文章推荐的新特性，仅使用三星的。
另外推荐阅读探秘ES6 系列
ES6的新特性是否通过babel转换后还有兼容问题？
团队中又同学正在验证，我们验证的环境是IE9+,ff,chrome，我们最终会使用三星特性加上兼容性ok的。
开发效率是否会有提高？
后面会通过做一个小的新需求，或者重构一个小模块去验证。
编译器高亮支持？
sublime Text 下面
https://github.com/babel/babel-sublime
或者
https://github.com/voronianski/oceanic-next-color-scheme
其实问题就这么多，比想象中简单许多，未来可能还有坑，但是至少我们开始尝试了。
红利
- 语法有问题时，编译报错——语法检查
- 面向未来——未来很多源码都是预编译类型
- 开阔前端思路
- 能读懂以后牛逼框架的源码， angular2 使用typescript
微信公众号
