New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.
Already on GitHub? Sign in to your account
Request for Compilation Option to Avoid Reflect.construct in Babel Transpilation #16246
Comments
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. |
I'm surprised that |
Indeed, that's exactly what I did. Thanks |
馃捇
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
The text was updated successfully, but these errors were encountered: