@poke707 用 ES 6 好处很大么？ 我倒觉得变复杂了。我只喜欢 async await ，可以还没有。
就算浏览器准备好了，你也不会去掉转义的，因为 babel 用上了就停不下来，这只是我猜啊。
要真是与代码无关就好了，最大的关系就是能不能直接运行。我就是很在意，我写的代码不能运行这件事。
我也很在意，以后不能直接操作 DOM 这件事。也很在意， CSS 要写成 JS 。也很在意 Event 都不能用了。

这还是 Web 吗？

@miyuki 因为他没有被垃圾邮件轰炸过。想暴露一下自己的私人邮箱来试试，哈哈

@Sparetire 你的翻译不对吧……我在吐槽现在的新框架对工具依赖太重，没有工具，无法写代码，因为代码不能运行在浏览器里。

@zjfeng 我一直在一线互联网公司呀……

f*rk me -> 叉（插）我

@zjfeng @zjfeng 你说的我不分认同，但真没那么多复杂项目，我做过最复杂的事在线图片编辑，也是用 backbone 做的

@xsstomy
@Balthild
即使考虑需求，我还是认为， 90% 的网站，不需要这么复杂的工具和框架。
也就在线 IDE 、编辑器、作图工具，才需要搞这么复杂。

@ianva 当然其实我是有一个基于 jQ 的小框架的，不过改进不大，唯一的改进就是不需要 watch ，用原生，有 MVC 、有组件、利用原生 DOM Event 做模块通信，用在 1688.com 的商家页面里了，并没有好到可以秒杀其他。

@ianva 这些技术我都用了……边用边吐槽。如果我有更好的，我就发了。

@lovelypig5 我不认为现在前端的工程化是好的工程化，就说一个，版本依赖问题，
假设我有个前端基础库 class.js
然后所有组件（ c1.js c2.js c3.js ... c10.js ）依赖 class.js
然后页面依赖了 c1.js c2.js c3.js ... c10.js
好，现在 class.js 升级了，我是不是要去 c1.js ... c10.js 里全部改写 package.json ，发布一次。
当然，这不只是 JS 遇到的问题，其他语言也有，但这种情况在浏览器上是很麻烦的，因为你不能只升级 c1.js 而不升级 c2 ... c10 ，否则你的页面里就有两个版本的 class.js ……

这不是好的工程化，甚至比之前的 script 引入还要复杂和麻烦。

@lovelypig5 大意为着复杂，复杂意为着有 bug …… 我偏向于一行依赖都没有的原生 ES 语法。而不是构建在 70 兆 JS 代码上面的浏览器还没支持的最新 ES 语法。

@g0thic 你说的是，大公司之所以细分，目的之一就是这个。但是细分的缺点我也需要点明是不是。如果某些小公司不明就里，向大公司学习，搞前后分离，只会自己吃亏。

@lovelypig5 我是觉得前端工具已经可以用丧心病狂来形容了，一个简单的问题，被复杂化到不行了，现在加一个 babel ，得先下载 70 兆左右的 NPM 依赖，呵呵。

@lovelypig5 按照现在前端的节奏，永远不会去掉 polyfill 的

@lovelypig5 能有多少网页是 app 啊……淘宝手机客户端那些页面我都不认为应该全部做成 web app 。

@sox 那个也是功能之一，但是意义不大，跟 live reload 一个性质，节省几下鼠标点击而已。 如果 watch 太慢，你就必须加 hmr 了。

纠正： 我还是那个太少->我还是那个态度

现在的所谓前端工程化
1. minify - ok
2. less / sass - maybe ok ，毕竟 CSS 选择器写起来很麻烦，但也只是写起来爽了，稍微加快效率。
3. concat - maybe ok, HTTP/2 上了， concat 就收益不大了。
4. live reload - not ok 。 经常在我不想刷新的时候刷新了。
5. wabpack - 工程化，写起来爽了，没看出来解决了什么很大的问题。
6. jsx 、 bable 、 react - 全家桶， react 是选型问题，我还是那个太少， 90% 的网站不应该用 react
7. hot module replacement - 哈，是为了解决上面任务太多， watch 太慢，而不得不加的东西
8. 依赖分析 - 用上 CommonJS 后带来的副产品，文件太细，还想动态加载，又不想动态加载得太多，然后还延伸出更多关于依赖管理的问题，甚至改变了前端写代码的方式， inline script 直接不让写了。评价就是半成品的工程化，需要人为做很多事情。

@g0thic 你没觉得我那篇喷前后分离的是真相么……