Babel 转码后代码会变慢吗?

[iugo]

标题多多少少不严谨, 也可以这样问:

JavaScript 引擎对 ECMAScript 2015 及以上特性的支持有多大程度的性能优化?

不同 JavaScript 引擎的效果可能不一样, 比如 SpiderMonkey 和 V8 各有侧重.

所以不知道有没有一个服务, 对主流的 JavaScript 引擎和常见的 ECMAScript 2015 及以上特性做性能对比.

• 目前在用 Babel. 但一些项目用 TypeScript 后就不用 Babel 了.
• 根据我自己使用 Node.js 的经验, 没感觉 V8 对新特性在性能上有可感知的优化.

虽说 ECMAScript 2015 及之后都可以看作是语法糖, 但我相信 JavaScript 引擎和 Babel 对此的态度可完全不同. 只是不知道是否有值得一提的性能提升(比如某语法特性速度快 10% 这样).

[noe132]

应该是会变慢的。
对于一般 web 项目基本影响可以忽略。
不过引擎支持总比 polyfill 看的顺眼。可能有实现方式上的优化。
像 async generator 这东西翻译之后可谓是相当的复杂

[LancerComet]

大多数 Polyfill 都有 Native 支持检测，在下认为在浏览器支持的情况下，检测代码不会有值得一提的性能降低（但有些检测方式可能会让楼主觉得太长，比如 CoreJS 里的那些）

不过转换后的代码多多少少复杂度是上升的，按道理说是会减慢速度（一般都认为是初始化速度吧），但对于大多数产品来讲应该是可以接受的（问题还不到这个层面）

另外楼主的项目转向 TypeScript 后没有使用 Babel，说明 TS 直出的 ES5 代码满足楼主项目需求，所以在下推断项目复杂度可能不是非常复杂，也应该没有用到 Set/Map/Reflect 之类需要 Polyfill 的特性，对于这样的项目，也许 Babel 层面还不是瓶颈 _(:3 」∠ ❀)_

[LancerComet]

另外补充，如果楼主用的是 preset-env 的话可以试一试 loose 模式，可能 loose 模式下的代码看起来舒服一点吧，速度嘛感觉没啥区别 _(:3 」∠ ❀)_

[misaka19000]

还没怎么见到过需要提高性能的 js 代码 只要代码别写的太烂基本上都没太多问题 代码一般更看重的是可维护性