Re: [w3c/ServiceWorker] New "setup" lifecycle for service worker (#1576)

@hanguokai Understood and agreed.

My general point here is that there's no need for the ServiceWorkers spec to add explicit waits to its event dispatching semantics along the lines of Step 19 in [Handle Fetch](https://w3c.github.io/ServiceWorker/#on-fetch-request-algorithm) that says `If activeWorker’s state is "activating", wait for activeWorker’s state to become "activated".`  That is something that can entirely be dealt with by the WebExtensions consumption of ServiceWorkers in WebExtensions space if that's something WebExtensions want.

I understand the case you are making for use case commonality for (web) Service Workers, but I share @wanderview's complexity concerns and a general performance concern, as the general feedback we have received is that ServiceWorkers need to have the lowest latency possible, and introducing an intentional pipeline stall that precludes parallelism seems counter to that (and the UX that users want, as opposed to the DX that developers want).  WebExtensions operate in a somewhat different problem space where there's inherent user intent via the act of installation that justifies speculatively spinning up ServiceWorkers in response to potential actions like moving towards/hovering on a button and/or starting them at browser startup and keeping them alive for extended periods of time that would not make sense for websites.

I mentioned "fetch" because it was my impression that WebExtensions re-uses "fetch" rather than having introduced a distinct event type with its own semantics.  I may be wrong about this.

-- 
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/1576#issuecomment-814272265