Web 技术研究所

我一直坚信着,Web 将会成为未来应用程序的主流

丢掉 babel?太早了吧?

  使用 ES6 已经好长一段时间了,但还是一直都基于 babel 来跑。网络上一直在宣传「拥抱原生 ES6 丢掉 babel」,这是对的,是迟早的事情,但我觉得现在还不是时候。虽然 babel 的转换也不是很完美,而且很多特性的实现都有坑,但为什么非要纠结生成的代码不可呢?
  很多时候一些内部项目都被做成是 Chrome Only 的,然后 babel 就丢掉了。但是即便是内部项目,如果使用者很多的话现在也不能这么任性地直接上 ES6。如果使用一个东西要被限定浏览器,这不是很过分么?有没有考虑过 Firefox 用户的感受?或者说这种绑架用户的行为和以前那些 IE6 Only 网页有什么两样?
  虽然最新的 Firefox 和 Chrome 都支持了大部分 ES6 的特性,但它们的支持程度还是存在差别的。一个产品级的东西,即便是内部项目也好,完全无视掉这种兼容就有些过于激进了。产品还是应该考虑用户的,而不是完全为了技术而产品。实际上使用 babel 并不会增加多少工作量,甚至反而可以无视掉很多兼容上的考虑,让开发更快速。
  也许有人觉得 babel 转换出来的东西是一坨,实在太难受了。但是我们为什么要纠结转换出来的结果呢?其实很少会踩到 babel 的坑,至少我用了这么久从来没踩过坑。但是我确实也在规避一些坑比较大的特性,比如 Map、Set 之类的东西。
  也有人会纠结生成出来的代码性能是个坑?其实这样的担心很多余。虽然生成的代码是一坨奇奇怪怪的东西,比如 for-of 就会考虑迭代器之类的,就非常奇怪。但前端 JS 写得再烂也比 DOM 操作快吧?现代浏览器上的 JS 执行速度根本不是瓶颈,除非是 IE8 之类古董级内核。后端呢?JS 写得再烂也比跨服务器的数据库查询快得多吧?所以语言本身就不是个瓶颈,看看各种 PHP 项目都跑得好好的咱还担心啥?JS 写得再烂也比 PHP 快嘛(我在拉仇恨)。如果真有什么 CPU 密集型的运算,那也不该直接写在业务代码中。抽取成单独的模块用 ES5 写或者用 C++ 写 Node 插件才是正解。
  我并不是在阻止大家使用原生的 ES6,而是要分清产品级的东西和研发级的东西。
网名:
34.203.245.*
电子邮箱:
仅用于接收通知
提交 悄悄的告诉你,Ctrl+Enter 可以提交哦
神奇海螺
[查看全部主题]
各类Web技术问题讨论区
发起新主题
本模块采用即时聊天邮件通知的模式
让钛合金F5成为历史吧!
次碳酸钴的技术博客,文章原创,转载请保留原文链接 ^_^