Is there any practical difference between using babel-runtime and the babel-polyfill when *not* developing a library? (e.g. web application)

Question

It's all in the title, really.

In the Babel documentation, there is the following line on the page describing babel-runtime

Another purpose of this transformer is to create a sandboxed environment for your code. Built-ins such as Promise, Set and Map are aliased to core-js so you can use them seamlessly without having to require a globally polluting polyfill.

The polyfill is just that, a separate JavaScript file which is included which shims up some missing things.

I've tested the polyfill vs. using babel-runtime with my build tools (webpack), and my files are slightly smaller when I use babel-runtime.

I'm not developing a library or plugin, just a web application, and also do not care about the global scope being polluted. Knowing this, other than the slightly smaller final filesize, are there any other practical benefits or points in using the runtime over the polyfill?

Answer 1

If you don't care about polluting global scope, the polyfill is the better option: the runtime does not work with instance methods such as [0, 1, 2].includes(1), while the polyfill will.

The main difference between the two is that the polyfill pollutes global scope, and works with instance methods, while the runtime does not pollute global scope and does not work with instance methods.

The polyfill also will not allow you to include two separate versions of itself into your code. This is only a problem if two separate polyfills are being required/imported somewhere in your code.