Request for Compilation Option to Avoid Reflect.construct in Babel Transpilation

[Cola-Zhang]

💻

• Would you like to work on this feature?

What problem are you trying to solve?

I am facing performance issues in a JavaScript game I am developing due to the use of Reflect.construct for object creation when transpiling ES6 to ES5 with Babel. The method's performance overhead is causing low frame rates when a large number of objects are created, which is critical in a gaming context.

Describe the solution you'd like

I would like Babel to provide a compilation option that allows for ES6 to ES5 class transformation without using Reflect.construct. This option should enable a more performant alternative for object instantiation that aligns with the need for high-efficiency execution in applications like games, where rapid object creation is a common scenario.

Describe alternatives you've considered

As an alternative, I have manually modified the construct and isNativeReflectConstruct methods in @babel/helpers/lib/helpers-generated.js to bypass the use of Reflect.construct. While this approach works, it is not maintainable or scalable. Additionally, the loose mode is not a viable alternative due to compatibility issues it introduces with the complex class libraries used in my project. Therefore, a supported compilation option within Babel's official configuration would be the ideal solution.

Documentation, Adoption, Migration Strategy

No response

[babel-bot]

Hey @Cola-Zhang! We really appreciate you taking the time to report an issue. The collaborators on this project attempt to help as many people as possible, but we're a limited number of volunteers, so it's possible this won't be addressed swiftly.

If you need any help, or just have general Babel or JavaScript questions, we have a vibrant Slack community that typically always has someone willing to help. You can sign-up here for an invite.

[liuxingbaoyu]

I'm surprised that Reflect.construct makes a noticeable performance difference.
In this case I recommend you use patch-package to patch isNativeReflectConstruct, it should rarely change.

[Cola-Zhang]

I'm surprised that Reflect.construct makes a noticeable performance difference. In this case I recommend you use patch-package to patch isNativeReflectConstruct, it should rarely change.

Indeed, that's exactly what I did. Thanks