Skip to content
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’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature Request] Polyfill using dynamic import. #518

Closed
rockmandash opened this issue Mar 29, 2019 · 2 comments
Closed

[Feature Request] Polyfill using dynamic import. #518

rockmandash opened this issue Mar 29, 2019 · 2 comments

Comments

@rockmandash
Copy link

Thank you for this amazing and wonderful library! I use core-js every day, it saved my life.

I was wondering if there is any posibility that we can do this:

import('core-js').then(() => {
  // main code goes here.
  // ...
  // ...
})

I don't know if this is a good thing to do, but in this way, we can only loads minimum code that checks feature support all in once, and polyfill those feature after feature supports are all checked, then we can load the main code.

I think this way can reduce a lot of code, both support low-end browser and polyfill almost zero code when using a high-end browser.

And people don't have to remember which import statement to pick.

@zloirock
Copy link
Owner

zloirock commented Mar 30, 2019

It's a very interesting issue. Some days ago I found some related issues in babel's repo like babel/babel#8089 or babel/babel#9170. Some years ago I played with technics like this. However, I don't think that the proposed conception is a good idea.

Now we have core-js-compat test case and it can be used as a base for runtime checks for this conception, so a raw version of this could be implemented just for some hours. But the size of this runtime checker will be 25-30KB - 20-25% of the full core-js version size which will be loaded anyway. Sure, this size can be reduced by technics from preset-env with useBuiltIns: usage, but it will not reduce the percentage. More other, it's an additional request after loading of the bundle with this checker - it will seriously increase the page load time.

User-agent based conception looks much more interesting - runtime checker will not be required and we will immediately load only the required polyfills, see this note.

However, maintenance of a service like this requires much time and resources, but core-js is just my own hobby project and isn't backed by any company, so now I haven't those resources and time.

@zloirock
Copy link
Owner

Closed in favor of #638.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants