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.
It's a very interesting issue. Some days ago I found some related issues in babel's repo like https://github.com/babel/babel/issues/8089 or https://github.com/babel/babel/issues/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.
Most helpful comment
It's a very interesting issue. Some days ago I found some related issues in babel's repo like https://github.com/babel/babel/issues/8089 or https://github.com/babel/babel/issues/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-compattest 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 fullcore-jsversion size which will be loaded anyway. Sure, this size can be reduced by technics frompreset-envwithuseBuiltIns: 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-jsis just my own hobby project and isn't backed by any company, so now I haven't those resources and time.