You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This has two major benefits over including polyfills manually:
You don't have to worry about managing and including polyfills in your codebase. You write modern JS code and let the Polyfill service handle compatibility issues at the edge;
You're not serving polyfills to people that natively support them, avoiding sending unnecessary data across the wire.
The code behind Polyfill.io is available on GitHub and even though it can work as a standalone server, it can also be used as a Node.js module.
My think is that we could use it to extend CDN with the ability to automatically polyfill JS files. So you'd serve your JS file with modern code and CDN would inject any necessary polyfills depending on the client's browser.
I'm happy to have a stab at this if we think it's worth pursuing.
The text was updated successfully, but these errors were encountered:
I’ve been looking into polyfill.io recently too, but I ended up thinking: since it doesn’t completely replace transpiling (e.g. with Babel), what’s the real value? I can use babel-polyfill to get the same result as part of the build process. Or am I missing something?
@orinocai I think transpilation and polyfilling should be separate processes. For example, with Publish we're transpiling ES6 to ES5 at build stage with Babel, but the resulting bundle still includes ES5 code that isn't supported by some browsers (like Array.prototype.some or fetch, to name just a couple). Polyfill.io would be ideal to conditionally augment the bundle with the necessary polyfills.
And yes, you could add polyfills for these at build stage, but you'd be increasing the size of the bundle for everyone.
Also, you're assuming that everyone that needs to add polyfills will also have a transpiler, which may not be the case.