总结一下公司项目使用各种较新的前端技术和 Api 的一些经验。

关于 ES6:

需要注意 ES6 的一些特性和 API 是需要一个 200k 的 Polyfill 才能得到支持的，特性如 for ... of 循环，generator，API 如 Object.assign 等。我们的做法是放弃这些特性，单独引入对应 API 的 Polyfill 。

关于 Webpack：

Webpack 有一个 Code splitting 功能，墙裂推荐。Webpack 作者自己表示发明新轮子的原因就是因为其他工具没有 Code splitting 。

我们在做包体积优化这个事情的时候，看到有两个可能性：DllPlugin 和 Code splitting。严格来说，这两个方案不是解决同一件事情的，侧重点不一样。

DllPlugin 可以把依赖库和业务代码分开，这样一是能够提升编译效率，二是业务代码修改打出的包很小，每次修改，用户只需重新加载一个很小的业务代码的包。长期来看是非常省流量的做法。

Code splitting 做的事情是异步加载依赖包。有点像 RequireJS 。比如我有个页面有轮播的需求，引入了一个几十k的第三方库，而其他页面都用不到，我就可以使用 Code splitting 的特性，异步加载这个库。这样只有在用户访问特性页面才会加载这个库，否则这个流量就省了。

考虑到我们的上线并不十分频繁，DllPlugin 所带来的流量节省效果并不明显，所以我们优先引入了 Code splitting 方案。

Fetch 及 CORS： CORS 不是一个新技术，但是似乎因为兼容问题，业内用得不多，也可能是我孤陋寡闻。我们使用 CORS 的考虑是：

1: 想用 Fetch 但不想用 Fetch－jsonp 。

2: 需求都是来自移动端。

于是就上了 Fetch ＋ CORS 的方案。这里有一个小小的注意点：当开启 CORS 发出一个非简单请求（not-so-simple request）时，浏览器会发起一次预请求（详见：http://www.ruanyifeng.com/blog/2016/04/cors.html），预请求必须是一个简单请求（simple request），这件事情非常好理解：我在发一个非简单请求之前，需要询问服务器这个非简单请求包含的特殊字段能不能发，那么一定不能在询问的时候就已经带上了这些个特殊字段，否则预请求存在的意义是什么。

还有什么想到了再补充吧。。