Re: [w3c/ServiceWorker] importScripts() on ServiceWorkerGlobalScope (#1319)

>I'd still like you to create a new issue fwiw.

It's a steep curve for me. I thought I'd find a contributor who understands the thing I'm talking about first.

> What ability do you feel import() is getting in #1585 that doesn't already exist in importScripts?

AFAICT, it's the ability to load local/offline code dynamically on demand. Currently, we can't use a dynamic `import()` and we can't use a dynamic (aka postponed/async/late) `importScripts`. Either of them would allow us to have a tiny fast-to-load service worker that runs only the bare minimum of code on an event, imports another specialized script for that type of event/route, and passes the event to that script to handle.

Theoretically, just having a dynamic `import()` solves the problem for modern codebases but an async/late `importScripts` is still useful to import legacy code that exposes global variables/functions without going through the hassle of wrapping it into a module using a WebPack plugin, for example. There are thousands of such libraries around that are still useful and not maintained.

> If possible please demonstrate with a reduced runnable example of the issue.

A contrived example:
```js
self.addEventListener('fetch', e => {
  e.respondWith(import(getScriptNameForRequest(e)).then(m => m.default(e)));
});
```
Similarly for importScripts:
```js
self.addEventListener('fetch', e => {
  if (someCondition(e)) {
    importScripts('./foo.js');
    e.respondWith(foo(e));
  }
});
```
In case of Chrome extensions ManifestV3, the only difference is that they have lots of API events.

-- 
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/1319#issuecomment-856654753