推荐关注
› Meteor
› JSLint - a JavaScript code quality tool
› jsFiddle
› D3.js
› WebStorm
推荐书目
› JavaScript 权威指南第 5 版
› Closure: The Definitive Guide
› Closure: The Definitive Guide
这是一个创建于 2467 天前的主题，其中的信息可能已经有所发展或是发生改变。
标题多多少少不严谨, 也可以这样问:
JavaScript 引擎对 ECMAScript 2015 及以上特性的支持有多大程度的性能优化?
不同 JavaScript 引擎的效果可能不一样, 比如 SpiderMonkey 和 V8 各有侧重.
所以不知道有没有一个服务, 对主流的 JavaScript 引擎和常见的 ECMAScript 2015 及以上特性做性能对比.
- 目前在用 Babel. 但一些项目用 TypeScript 后就不用 Babel 了.
- 根据我自己使用 Node.js 的经验, 没感觉 V8 对新特性在性能上有可感知的优化.
虽说 ECMAScript 2015 及之后都可以看作是语法糖, 但我相信 JavaScript 引擎和 Babel 对此的态度可完全不同. 只是不知道是否有值得一提的性能提升(比如某语法特性速度快 10% 这样).
4 条回复 • 2018-02-24 20:10:53 +08:00
 |
1
noe132 2018-02-24 19:50:44 +08:00 via Android
应该是会变慢的。
对于一般 web 项目基本影响可以忽略。 不过引擎支持总比 polyfill 看的顺眼。可能有实现方式上的优化。 像 async generator 这东西翻译之后可谓是相当的复杂 |
 |
2
LancerComet 2018-02-24 20:07:08 +08:00
大多数 Polyfill 都有 Native 支持检测，在下认为在浏览器支持的情况下，检测代码不会有值得一提的性能降低（但有些检测方式可能会让楼主觉得太长，比如 CoreJS 里的那些）
不过转换后的代码多多少少复杂度是上升的，按道理说是会减慢速度（一般都认为是初始化速度吧），但对于大多数产品来讲应该是可以接受的（问题还不到这个层面） 另外楼主的项目转向 TypeScript 后没有使用 Babel，说明 TS 直出的 ES5 代码满足楼主项目需求，所以在下推断项目复杂度可能不是非常复杂，也应该没有用到 Set/Map/Reflect 之类需要 Polyfill 的特性，对于这样的项目，也许 Babel 层面还不是瓶颈 _(:3 」∠ ❀)_ |
|
3
LancerComet 2018-02-24 20:09:11 +08:00
另外补充，如果楼主用的是 preset-env 的话可以试一试 loose 模式，可能 loose 模式下的代码看起来舒服一点吧，速度嘛感觉没啥区别 _(:3 」∠ ❀)_
|
 |
4
misaka19000 2018-02-24 20:10:53 +08:00 via Android
还没怎么见到过需要提高性能的 js 代码 只要代码别写的太烂基本上都没太多问题 代码一般更看重的是可维护性
|
Select Language