Load polyfills from polyfill.io rather than babel-polyfill

babel-polyfill is very heavy, and the REPL loads it when you select the “evaluate” option. Let’s instead use a conditional polyfilling service like polyfill.io that only loads the polyfills your browser actually needs. I’d say that most users of the REPL would be using a relatively modern browser, so this should reduce load time.

We’ll need to be sure to load the regenerator runtime though.

import "regenerator-runtime/runtime";

[zloirock]

@thedamon by my opinion, polyfill.io is a good service with bad polyfills.

You can see polyfill.io position about the correctness of polyfills here. You can check the source code of polyfills from polyfill.io in their repo. Just an example - leaking WeakMap polyfill. They have some progress in the previous year, but because they regularly have issues like this, I can’t recommend it for usage. polyfill.io use polyfills from different authors/projects which doesn’t well play together.

core-js / babel-polyfill includes much more features than polyfill.io. Just some example - regenerator runtime for generators / async functions, polyfills for ES proposals, typed arrays, the logic of almost all well-known symbols, etc.

105kb of babel-polyfill you will have only with full bundle, but it’s modular. You can load only required part of core-js. You can automatize this process with preset-env with useBuiltIns option.

polyfill.io service approach definitely makes sense, it can by applied to core-js in the future, but now I haven’t any time and motivation for working on it.

[zloirock]

I’m strictly against of usage polyfill.io in the REPL because it contains very incorrect polyfills and only a little part of polyfilled features from babel-polyfill.