Support for legacy browsers?

[slavafomin]

Hello!

Thank you for this great polyfill!

However, from the looks of it, it requires at least some basic features of the EcmaScript Modules to be available in the browser. Such features are not available in older legacy browsers, like Internet Explorer 11, for example. Does it means that this polyfill can't be used with such browsers? Or maybe, there is a way to make it work with yet another polyfill?

Regarding the above, why aren't you using XHR/Fetch with eval/Function approach to make it more compatible with older browsers? Do you think such approach has a drawbacks of it's own?

Thank you!

[philipwalton]

from the looks of it, it requires at least some basic features of the EcmaScript Modules to be available in the browser.

Yes, that's correct. The polyfill is not intended to be used with older browsers. For that, you have to use <script nomodule>, which I show an example of in my polyfill demo. (I also wrote an article a while back on exactly this topic that you might find interesting).

Regarding the above, why aren't you using XHR/Fetch with eval/Function approach to make it more compatible with older browsers? Do you think such approach has a drawbacks of it's own?

Yes, there are lots of drawbacks.

• If the module your importing contains its own import statements, those imports will need to be recursively fetched and eval()-ed (essentially, you'd have to re-implement the browser's module loader logic yourself)
• If you're in IE11 and the module you're importing uses ES2015+ syntax, you'd have to transpile that syntax to ES5 before you eval()-ed it, otherwise there'd be errors.

The code required to do both of the above would make this polyfill enormous and unusable in any real performant way.

A much better approach (the one I use in the demo), is to only use the dynamic import polyfill in cases where the browser already supports modules. You can then use a traditional bundler/transpile to handle IE11 and other legacy browsers.

Does that make sense?

[slavafomin]

Thank you @philipwalton for a thorough explanation, now I see your point more clearly.

Yes, I've already read your articles (which are great), just wanted to clear out some details.

The polyfill is not intended to be used with older browsers. For that, you have to use <script nomodule>

And the code provided as a nomodule shouldn't use the dynamic imports or should rely on some other technology to load external modules, right?

---

Let me explain our use case. We are not using ESM modules in the browser at the moment and we transpile everything to the IE 11 level using Babel and Browserslist. However, we do want to split our code into multiple bundles and load them dynamically in runtime. The most future-proof way of doing this, in my opinion, is using ES dynamic import syntax, so I was looking for polyfills to enable support for such syntax in older browsers.

Considering our scenario and the need to support IE 11, do you think that using XHR/Fetch + eval()/Function is the only viable option for us?

[philipwalton]

I would fallback to something like SystemJS or an AMD module loader (like RequireJS). You'll probably find this comment thread useful. It's similar to your question and discusses dynamic script loading for the legacy bundle.

I wouldn't write something to do this yourself, as there are lots of well-tested tools that handle dynamic script loading and all the complexities around that (and already work with Rollup).

[slavafomin]

Thank you @philipwalton for clarifying that. I was exactly looking into using SystemJS + Rollup's dynamicImportFunction option. I think that this would be the most concise way in order to support legacy browsers.

Maybe we could add this use case to the README section of the package? So other developers could easily find information regarding this scenario.