| 01:34 | <jolvera> | i'd like to contribute again and i'm looking at https://github.com/whatwg/html/issues/4626 but i'm not sure what a "WPT test" is |
| 01:37 | <jolvera> | nvm i just read the readme.md |
| 05:17 | <annevk> | jolvera: great, be sure to let this channel know if you run into issues |
| 08:17 | <annevk> | Domenic: per https://w3c.github.io/ServiceWorker/#importscripts importScripts() will return a network error which I guess will result in a script error so we might have some of those on whatwg.org? |
| 08:25 | <annevk> | JakeA: https://github.com/tc39/proposal-top-level-await/issues/79 |
| 08:29 | <JakeA> | annevk: yep, I agree. I can't think of anything good you could do with top-level await in service workers |
| 08:33 | <annevk> | JakeA: cool, I think littledan is open to making this change and hopefully nobody in TC39 cares too much about some agents not having it |
| 08:33 | <annevk> | JakeA: though it reached stage 3 just now, so it'd be hard to block anyway :p |
| 08:45 | <littledan> | as an example of somewhere this might come up, if you want to use a WebAssembly module, it'd run into this restriction, since we like to give Wasm time to compile itself off the main thread |
| 08:45 | <littledan> | but I guess people could get around this by loading the Wasm module later, after initial startup (?) |
| 08:46 | <littledan> | JakeA: Does that sound reasonable to you? I'm happy to write this up in spec text if this is what we're agreeing on |
| 08:47 | <annevk> | Ideally a service worker is a Wasm module I think |
| 08:48 | <JakeA> | littledan: how is the wasm imported into the service worker in this case? |
| 08:48 | <littledan> | I was getting at, it could be with an import statement, with Wasm/ESM integration. |
| 08:48 | <littledan> | (which isn't implemented anywhere, but everyone seems to buy into it) |
| 08:49 | <JakeA> | So `import wasmModule from './whatever.wasm'` - are you saying this uses top level await internally? |
| 08:49 | <littledan> | JakeA: Yes, that's the proposal |
| 08:49 | <littledan> | JakeA: So Wasm "compilation" takes place when fetching/parsing ,but some engines (currently JSC, but maybe more in the future) do significant work when "instantiating", which happens in the ESM evaluation phase |
| 08:50 | <littledan> | JakeA: So, the spec is, "in parallel, queue a task to..." |
| 08:50 | <JakeA> | littledan: how is its use of `await` observably different from the parse time a regular script does when importing? |
| 08:51 | <JakeA> | I guess I'm trying to figure out what it means to use `await` 'internally' |
| 08:51 | <littledan> | JakeA: Not sure what you mean by "observably". It's like, if you have one module which imports another, the dependency doesn't run its top-level statements until the inner `await` resolves |
| 08:51 | <littledan> | and then, at the top level, there's a concept of when we've asynchronously finished executing the module graph, rather than synchronously (but it's fine to ignore this--HTML doesn't use it for much) |
| 08:53 | <littledan> | JakeA: Here's a simple, silly example: https://github.com/tc39/proposal-top-level-await#solution-top-level-await |
| 08:54 | <JakeA> | littledan: what if `import wasmModule from './whatever.wasm'` didn't use `await` internally, and it just waited. What would the observable difference be? |
| 08:54 | <JakeA> | littledan: but those examples aren't an internal use of `await`, they're author-written |
| 08:54 | <JakeA> | or have I misunderstood how `import wasmModule from './whatever.wasm'` is supposed to work? |
| 08:55 | <littledan> | JakeA: Right, in the draft spec for Wasm modules, we *always* queue a task (for consistency), so if that module calls into JS from its start function, you can see the timing difference |
| 08:56 | <littledan> | smaug____ and others were pretty strong in encouraging consistency on whether we're queueing a task or just preceding synchronously (in an earlier draft, it was "optional") |
| 08:56 | <JakeA> | littledan: consistency with what? (sorry I'm being dumb) |
| 08:57 | <littledan> | JakeA: Among engines, or within an engine, what the timing will be |
| 08:57 | <JakeA> | littledan: but if wasm modules consistently _didn't_ queue a task, would that be inconsistent with something else? |
| 09:01 | <littledan> | JakeA: Well, it'd mean we're running compilation on the main thread, which isn't so great |
| 09:01 | <littledan> | not sure how deep you're interested in the details of why that'd happen |
| 09:02 | <littledan> | Working out these Wasm module interactions is why I got started on top-level await |
| 09:03 | <JakeA> | littledan: Gotcha. I guess this relates more to https://github.com/tc39/proposal-top-level-await/issues/79#issuecomment-499402046 then. Allowing `import()` means you can kick off the import early but not be blocked by the compilation |
| 09:04 | <littledan> | right, I could imagine telling SW programmers, "sorry, Wasm has to be done with import()". I would be a little sad about that, but not the end of the world |
| 09:04 | <littledan> | JakeA: Is this what you're thinking? |
| 09:04 | <littledan> | JakeA: Or are you thinking, we do compilation on the main thread in this case, and off the main thread in that case? |
| 09:04 | <JakeA> | littledan: The alternative is "WASM can be imported statically within a service worker, but oh god please don't" |
| 09:05 | <JakeA> | littledan: Nah I wasn't thinking about switching to main thread compilation |
| 09:06 | <littledan> | well, I still have to learn more about SW to understand exactly how bad this is. This isn't the same order as waiting for network stuff, I think |
| 09:06 | <JakeA> | littledan: The choice still feels like "disallow it" vs "allow it but firefight people actually doing it" |
| 09:06 | <JakeA> | littledan: Service worker startup is never blocked on network stuff |
| 09:06 | <JakeA> | littledan: except the very first time, but at that point the service worker isn't needed for an important event |
| 09:07 | <littledan> | OK, so, I'll draft up this text to prohibit async modules for serviceworkers and socialize it a bit, and we'll go from there |
| 09:07 | <littledan> | JakeA: Thanks for talking this through |
| 09:09 | <JakeA> | littledan: When a service worker is first run, it's in an 'installing' state. It isn't in the blocking path for fetch/push/sync/etc events. At this point we take everything it imports via `importScripts` (we'd do the same with static imports) and cache them alongside the worker script. Then, when the service worker is in the middle of those important events, we just pull the imported scripts from disk (potentially precompiled). If |
| 09:09 | <JakeA> | it tries to `importScripts` anything it hasn't already imported, it throws. |
| 09:10 | <littledan> | so, if we're importing something that's already cached in the SW, maybe it can be synchronous? |
| 09:11 | <JakeA> | littledan: if it can be cached, yeah |
| 09:12 | <JakeA> | littledan: but if one of the static imports `await`s a load of IDB work (for instance), which adds 100s if ms to the `fetch` event being dispatchable, that's what we want to avoid |
| 09:12 | <littledan> | I see |
| 09:12 | <JakeA> | of ms* |
| 09:12 | <littledan> | JakeA: yeah, I imagine TLA would be used for exactly that kind of thing |
| 09:13 | <littledan> | and when it's "dispatchable" is really about, when the module has run? |
| 09:13 | <JakeA> | yeah |
| 09:13 | <JakeA> | We can't dispatch it until `addEventListener('fetch', listener)` has had time to be called |
| 09:14 | <JakeA> | Which is once the script has run |
| 10:54 | <GPHemsley> | looks like I'm gonna be updating the wiki this weekend, as our current version of MediaWiki is going EOL this month |
| 11:41 | <Domenic> | <3 GPHemsley |