| 04:23 | <Mathieu Hofman> | I still don't understand why service workers can't wait until all modules have fully evaluated to deliver the events. The implementations ought to be capable of detecting when the evaluation won't make further forward progress, and error if the module graph has not been fully evaluated, indicating a top level await is suspended on an event to be delivered, which should be the only violation. |
| 06:51 | <Jack Works> | yes they can, but I think that will be a deficit in the user experience (I don't know but I think web requests are blocked until sw initialized) |
| 08:57 | <annevk> | Indeed, a goal with SWs is that the runtime can be instantiated and discarded quickly. If instantiation needs to be awaited, that would go counter to those goals. https://github.com/w3c/ServiceWorker/issues/1407 has a bunch of the background. |
| 12:45 | <Mathieu Hofman> | But a top level await does not necessarily mean an actual delay. It could be as short as a microtask for a resolved promise. A typical use case is awaiting a dynamic import, which is arguably equivalent to a static import (besides ahead of time module graph analysis). IMO discouraging bad patterns should not disable part of the language, it could instead be done the same way other bad patterns are discouraged: metrics and perf reports. |
| 12:59 | <littledan> | SWs make many other compromises of this type |