Re: [w3c/ServiceWorker] Clarify dynamic-imported scripts are never installed (#1356)

I'm currently shipping a polyfill for dynamic `import()` in ServiceWorker.
It dispatches synthetic FetchEvents, parses and flattens all the module scripts into one "classic script", then executes it using `new Function(...)`, resolving to a module shaped object.
Conditionally loading modules is in practice indispensable for shifting large, rarely used routes out of the load/parse critical path, with further gains from sharing code between `SharedWorker`/`ServiceWorker`.

Obviously I was banking on eventually retiring the eval polyfill.

It's not evident why dynamic `import()` presents the alleged risk, compared to literally any other critical code or data resource, or why normal async error handling suddenly becomes insufficient here.
For example, a route that is fulfilled by a WebAssembly module. My WASM module must be retrieved from the Cache and instantiated at run-time inside the fetch event.
Or consider when dedicated `Workers` are added to `ServiceWorker`, we'll be in the ridiculous situation where a route can be satisfied by a module running inside a `Worker`, but not by that same module simply imported in-place.

ES6 modules will reach their full potential once they work consistently across all execution contexts (`Window/Worklet/Worker/SharedWorker/ServiceWorker`). Dynamic `import()` is not analogous to either `importScripts()` or `fetch()`. ES6 modules are their own thing and they need to work as expected.

Finally consider the active proposals to overload dynamic `import()` with further capabilities such as loading JSON. Not only would `ServiceWorker` suffer reduced functionality, but it will continue to lose functionality over time.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/issues/1356#issuecomment-764226089