00:27:51  * gibson042joined
00:39:24  * AtumTquit (Quit: AtumT)
00:46:19  * aki_joined
00:47:07  * akirosequit (Ping timeout: 245 seconds)
00:47:07  * aki_changed nick to akirose
01:01:30  * cybaijoined
01:39:35  <Domenic>littledan: I would be against that; it ruins the ability to transparently refactor your work to take on async startup costs
01:40:00  <Domenic>If you're willing to rewrite the calling module graph anyway then you can just refactor to put everything inside dynamic imports
01:44:17  <gibson042>annevk: https://github.com/tc39/proposal-uniform-interchange-date-parsing is still active, I've just been short on time lately
02:52:29  * aki_joined
02:53:54  * akirosequit (Ping timeout: 268 seconds)
02:53:55  * aki_changed nick to akirose
02:58:38  <ljharb>that transparent ability is the
02:58:50  <ljharb>“Spooky action at a distance” that i have major concerns with :-/
03:01:53  <devsnek>littledan: along the same vein as domenic, you'd have to know if what you're importing is async or not, which is an annoying experience
03:22:45  * howdoijoined
03:24:32  * gibson042quit (Quit: Leaving.)
03:44:27  <ljharb>devsnek: you’d get an early error about that tho
03:44:38  <ljharb>it’d even be an autofixable lint rule
03:45:28  <devsnek>🤷
03:50:51  * hellauerquit (Ping timeout: 252 seconds)
03:52:53  * hellauerjoined
04:21:44  * hellauerquit (Quit: WeeChat 2.4)
04:29:23  * jmdyckquit (Remote host closed the connection)
04:58:41  * aki_joined
04:59:37  * akirosequit (Ping timeout: 245 seconds)
04:59:37  * aki_changed nick to akirose
05:53:43  * Jessidhiaquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
05:56:16  * Jessidhiajoined
06:16:54  * jwaldenquit (Quit: ChatZilla 0.9.92-rdmsoft [XULRunner 35.0.1/20150122214805])
06:44:01  * Jessidhiaquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
07:01:54  * Jessidhiajoined
07:05:15  * aki_joined
07:06:03  * akirosequit (Ping timeout: 246 seconds)
07:06:03  * aki_changed nick to akirose
07:46:04  * Jessidhiaquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
07:47:00  * Jessidhiajoined
09:11:41  * aki_joined
09:13:09  * akirosequit (Ping timeout: 268 seconds)
09:13:10  * aki_changed nick to akirose
09:29:21  <littledan>ljharb: I thought `import await` would fix those exact spooky action a distance issues. Ultimately, the vitality is analogous to the virality of async/await itself
09:31:53  <littledan>Domenic, devsnek: I can see this point abstractly, but isn't this just like async functions, which also require the caller to be adjusted to use a Promise rather than another value? We found it worth it to add async functions even though you could just use generators and Promises.
09:32:41  <littledan>What I am missing is usage scenarios where you want to change a deep dependency like that. The current TLA explainer doesn't really have one concretely, making it hard to think about
09:33:43  <littledan>I don't see what dynamic imports have to do with any of this, though; why would refactoring to those solve this problem?
09:35:07  * kpattichajoined
09:53:50  * cybaiquit (Remote host closed the connection)
10:03:40  * cybaijoined
10:07:41  * cybaiquit (Ping timeout: 246 seconds)
10:08:02  * kpattichaquit (Ping timeout: 268 seconds)
10:19:32  * kpattichajoined
10:53:40  * obensour1quit (Ping timeout: 246 seconds)
11:01:21  * hellauerjoined
11:08:20  * obensour1joined
11:18:20  * aki_joined
11:19:13  * akirosequit (Ping timeout: 245 seconds)
11:19:13  * aki_changed nick to akirose
11:31:02  <littledan>s/vitality/virality/
11:32:30  * jmdyckjoined
12:01:14  <Domenic>littledan: consider a web component whose template you want to move to another file
12:01:43  <Domenic>If you are going to change all call sites anyway you can use the import() + export default async antipattern the readme calls out.
12:03:57  <Domenic>The whole point of top-level await is to avoid making changes to the caller. I would be opposed to the proposal if it required caller changes.
12:22:28  * cybaijoined
12:27:14  * cybaiquit (Ping timeout: 272 seconds)
12:49:35  * cybaijoined
12:53:31  * AtumTjoined
12:54:28  * cybaiquit (Ping timeout: 272 seconds)
12:57:23  * cybaijoined
13:01:56  * cybaiquit (Ping timeout: 268 seconds)
13:13:10  * gibson042joined
13:16:18  * AtumTquit (Ping timeout: 245 seconds)
13:24:31  * aki_joined
13:25:36  * akirosequit (Ping timeout: 250 seconds)
13:25:36  * aki_changed nick to akirose
14:01:16  * AtumTjoined
14:18:16  * mgoljoined
14:43:09  * cybaijoined
15:31:16  * aki_joined
15:32:08  * akirosequit (Ping timeout: 250 seconds)
15:32:08  * aki_changed nick to akirose
16:06:45  * cybaiquit (Remote host closed the connection)
16:28:17  * akirosequit (Quit: 👋🏻)
16:29:40  * akirosejoined
16:33:23  <littledan>Domenic, I think it's still more ergonomic than nothing. I don't quite understand that other case--why would you export the element rather than defining it (in the background than blocking module loading)?
16:33:47  <Domenic>littledan: consider the example at https://github.com/tc39/proposal-top-level-await/issues/58#issuecomment-468749512
16:34:03  <Domenic>Consider a "before" version which had `const template = .... long string here ...`
16:34:22  <Domenic>You're saying I cannot switch to the version in the comment which loads the template from ./template-1.html without changing all my callers
16:34:32  <Domenic>I don't think top-level await is worth moving forward as an ergonomics feature
16:34:38  <Domenic>It is fundamentally an abstraction boundary feature
16:34:43  <Domenic>wycats made this point in previous meetings
16:39:29  * Nimelrianjoined
16:39:53  <littledan>To be clear, I still think it makes sense to have both imports run in parallel
16:41:36  <devsnek>`await import` does also imply some ordering
16:41:59  <Domenic>+1 devsnek
16:42:03  <Domenic>littledan: I was just using that code sample
16:42:07  <Domenic>Let me create a separate one to be clearer
16:46:17  * cybaijoined
16:46:36  <devsnek>heh the current proposal looks a lot like my implementation of top level await in engine262
16:51:10  * cybaiquit (Ping timeout: 255 seconds)
16:52:18  <Domenic>https://github.com/tc39/proposal-top-level-await/pull/60#issuecomment-473362344
16:55:19  <littledan>devsnek: Maybe, but I don't think anyone is proposing that
16:55:32  <devsnek>i just mean from a design standpoint
16:55:42  <devsnek>i didn't assume you were proposing such a thing
16:57:33  <littledan>Right, well, I was hoping that `import await` would make it feel like the whole awaiting action is hoisted to the top and done in parallel, just like the fetch for the `import`.
16:57:47  <littledan>devsnek: Do you think it achieves that?
16:58:10  <devsnek>i am unsure
16:58:54  <devsnek>domenic gave me an idea though
16:59:09  <devsnek>if all import statements are import await statements
17:00:46  <littledan>well, that's basically what you get from #49 or E57
17:00:51  <littledan>#57
17:01:04  <littledan>the idea of this PR is that import statements stay import statements
17:11:19  * kpattichaquit (Quit: Leaving)
17:13:33  * mgolquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
17:16:14  <ljharb>littledan: `import await` fixes it for the modules that add TLA; but it just moves it to the one that adds `import await`
17:19:10  <ljharb>to be specific, i don’t think adding TLA *should* be transparent. Maybe it should be viral, maybe not, but making a sync thing async is always a breaking change so far.
17:23:38  * obensour1quit (Ping timeout: 272 seconds)
17:35:56  * hellauerquit (Quit: WeeChat 2.4)
17:37:19  * obensour1joined
17:43:30  <littledan>ljharb: I don't understand what you mean by moving it. In particular, if you import a module that contains an import await, it's an error (at linking time)
17:43:42  <littledan>so, it remains a breaking change
17:44:05  <littledan>it's just like async functions: you need an await all the way up the callstack, if you want to get the value
17:44:15  <ljharb>right. But if i import a module that suddenly adds import await, that’s a breaking change too
17:44:32  <ljharb>and in the case of promises, you don’t - you could mutate a binding when the promise resolves without having to export a promise
17:44:40  <ljharb>or you could dispatch to different behavior, etc
17:44:47  <ljharb>the actual interface doesn’t have to change
17:45:11  <ljharb>atm there’s no way to consume a module using TLA that encapsulates that decision from *your* users.
17:45:22  <devsnek>i've kinda imagined that TLA is more useful at the entry rather than dependencies
17:45:23  <ljharb>hm, i guess dynamic import
17:45:33  <Domenic>At the moment consuming a module that uses TLA is ENTIRELY encapsulated from your users
17:45:42  <Domenic>The change to use `await import` would break that, which is why I'm objecting ot it
17:45:42  <ljharb>yes, my preference would be to only ever allow it in entry points, but there’s no way to spec that
17:45:55  <ljharb>Domenic: using TLA changes ordering and timing semantics tho
17:45:58  <ljharb>doesn’t it?
17:46:03  <Domenic>Yes, OK, "ENTIRELY" was over-strong
17:46:04  <devsnek>"it is an early error if module includes top level await and export"
17:46:12  <Domenic>If you don't use tick-counting trickery then it's unobservable
17:46:14  <ljharb>thus it’s still a breaking change, just a silent one
17:46:20  <ljharb>if it is ever observable then it’s observable imo
17:46:28  <Domenic>Sure. It's an observable change
17:46:31  <Domenic>Just one that's highly encapsulated
17:46:45  <ljharb>so i either want it to be entirely unobservable, trickery or not, or, i want it to be explicitly and loudly a breaking change
17:46:53  <ljharb>the middle is where confusion happens
17:46:53  <Domenic>OK. Then I don't think this feature will move forward.
17:47:15  <ljharb>what would the downstream consequences of that be?
17:47:32  <ljharb>in html, node, wasm, etc
17:47:36  <devsnek>i wouldn't agree that the number of ticks something takes is grounds to call it breaking
17:48:03  <ljharb>devsnek: when it goes from 1 to > 1, no, but when it goes from effectively 0 to > 0, yes
17:48:16  <devsnek>and i don't think anything except js itself wants async during evaluation phase
17:48:32  <devsnek>actually scratch that i know nothing about html imports
17:48:59  <ljharb>so that’s my question. Before declaring a feature deadlocked, I’d like to understand what bad things could happen without it
17:49:26  <ljharb>like E.g. if weakrefs died, wasm would ship them anyways, and then js would be forced to use wasm’s version
17:49:39  <ljharb>what happens downstream without TLA, looking far forward?
17:49:50  <devsnek>IIFEs continue to exist
17:51:27  <devsnek>it looks like importing an html returns that html as an element
17:53:18  <Domenic>We're still working moving the web from 0 ticks to >0 ticks
17:54:19  <devsnek>looks like importing html isn't hurt by the lack of async either
17:55:18  <Domenic>I mean, importing HTML will definitely be async
17:55:34  <Domenic>So I guess people could get around lack of top-level await by wrapping their .mjs files in .html files
17:57:04  <devsnek>i mean there's nothing imperative about html modules that require fancy async during the evaluation phase
17:57:17  <devsnek>not that they should be loaded synchronously :P
17:58:08  * annevkwhispers .mhtml*
17:58:12  <Domenic>Well they can include <script type="module">
17:58:16  <Domenic>Which is loaded async
17:58:32  <devsnek>i'd assume that's like having an import()
17:58:34  <devsnek>new entry point
17:58:44  <Domenic>Nah that's not the current proposal
17:58:48  <Domenic>They re-export any <script>s
17:58:59  <Domenic>Or maybe just the first one
17:59:11  <devsnek>interesting
17:59:30  <devsnek>that still fits within the current evaluation rules though right?
17:59:32  <Domenic>All of them, it looks like
17:59:33  <Domenic>https://github.com/w3c/webcomponents/blob/gh-pages/proposals/html-module-spec-changes.md
18:00:14  <Domenic>I mean HTML just evaluates modules on its own
18:00:20  <devsnek>yeah
18:00:30  <Domenic>It currently follows ES's everything-is-sync all-one-graph evaluation but that's changing
18:06:21  * mgoljoined
18:36:16  * aki_joined
18:37:07  * akirosequit (Ping timeout: 245 seconds)
18:37:07  * aki_changed nick to akirose
18:37:17  * hellauerjoined
18:44:39  * hellauerquit (Ping timeout: 252 seconds)
18:45:49  * hellauerjoined
19:01:26  * cybaijoined
19:05:52  * cybaiquit (Ping timeout: 245 seconds)
19:33:21  * jwaldenjoined
19:59:12  * howdoiquit (Quit: Connection closed for inactivity)
20:42:29  * aki_joined
20:43:49  * akirosequit (Ping timeout: 255 seconds)
20:43:49  * aki_changed nick to akirose
21:58:13  * jmdyck1joined
21:58:47  * jmdyckquit (Ping timeout: 245 seconds)
22:03:39  * gibson042quit (Quit: Leaving.)
22:07:09  <littledan>ljharb, WebAssembly modules also need to be async, as mentioned in the TLA explainer
22:07:22  <littledan>Domenic: Where can I find discussion about why HTML modules are async? I missed that.
22:08:34  <littledan>ljharb: I still don't understand why `import await` wouldn't meet your goals. I think it's "explicitly and loudly a breaking change", as you put it.
22:08:34  <devsnek>littledan: why does wasm need async?
22:08:56  <devsnek>it doesn't even *do* anything unless you have a start point
22:08:56  <littledan>https://github.com/tc39/proposal-top-level-await#webassembly-modules
22:09:15  <devsnek>and if you have a start point
22:09:17  <littledan>it might have to do compilation during the Evaluate phase, due to what the imports are
22:09:26  <devsnek>its not like you can await inside wasm
22:09:32  <littledan>these things are hard to reason about from first principles but come from real implementations
22:10:32  <devsnek>how is instantiation not part of the linking phase
22:11:27  * Nimelrianquit (Ping timeout: 252 seconds)
22:11:32  <littledan>See a detailed explanation in https://github.com/WebAssembly/esm-integration/tree/master/proposals/esm-integration
22:11:32  <devsnek>is this because of "From HTML, it’s not observable when parse a WebAssembly module begins, so any work perfomed in compilation may be performed off-thread."?
22:12:11  <devsnek>reading a file is async too, but we can still export things from source text
22:12:15  <littledan>Some compilation work might happen when parsing a WebAssembly module (nothing happens in the linking phase), but some other work might be needed once the imports are known
22:12:32  <devsnek>this causes me immense confusion
22:12:34  <littledan>in particular, some implementations have multiple types of underlying memory, and need to recompile due to that
22:12:44  <littledan>if you import a memory
22:13:07  <devsnek>that sounds like it would break the js api
22:13:19  <littledan>well, it doesn't, it's just that the JS API isn't very useful...
22:13:25  <littledan>you should only use instantiateStreaming for this reason
22:13:40  <littledan>probably the Wasm JS API should've been designed very differently, but it's a little too late
22:14:15  <littledan>the API just forces compilation work to happen on the main thread when you hold it wrong. Wasm modules will not compile on the main thread.
22:14:34  <littledan>the whole point of Wasm/ESM integration is to make the right way easy
22:14:36  <devsnek>you can use instantiateStreaming in a module loader today right now
22:14:41  <littledan>ype
22:14:43  <littledan>yep
22:15:23  <devsnek>not that its possible to easily test with cuz node refuses to merge any instantiateStreaming apis
22:15:35  <devsnek>but locally i've built all this already which is why i'm confused
22:16:27  <littledan>I mean, if you're testing it, the JS API "just works". It just might do compilation on the main thread. And these effects are engine-specific--JSC is the one which motivated this current issue.
22:17:11  <devsnek>are you saying that instantiation shouldn't happen during linking?
22:18:19  <littledan>Anyway, between HTML and WebAssembly, I think we really need modules to be able to be asynchronous. I wouldn't like to see more HTML willful violations governing things here, the way they do with the job/microtask queue; I'd like to find some sort of clean layering. But if the WebAssembly "do it anyway" case is motivating for you, that's sort of the risk here.
22:20:04  <devsnek>can you give me an example of a wasm module that demonstrates the need for async
22:24:59  * AtumT_joined
22:25:03  * AtumTquit (Ping timeout: 245 seconds)
22:33:47  <littledan>devsnek: No, because any of them may need to do compilation during instantiation. Please read the documents I linked which explain this in detail
22:35:56  <devsnek>i am seemingly missing the why from these documents
22:41:23  <devsnek>littledan: is this just that you want to allow recompilation to happen off thread?
22:41:32  <littledan>yes
22:41:53  <littledan>Seems like you understand; I'm wondering if you have ideas for how the documents could be more clear
22:43:19  <devsnek>what's the difference between my code needing to wait for something because it blocks vs needing to wait for something because its async
22:44:37  <devsnek>like within js code it makes sense to move things to the loop so you can keep going with other things, but your module graph has to wait either way
22:49:08  * aki_joined
22:50:00  * akirosequit (Ping timeout: 246 seconds)
22:50:00  * aki_changed nick to akirose
23:01:12  <devsnek>littledan: sorry to answer your question, i'd say the word "depend" is the wrong word, i was trying to figure out why it wouldn't be possible to add wasm modules without async when the actual situation was that it was just a bonus for performance
23:01:48  <littledan>exactly, but this performance bonus is an architectural thing. If we make them sync now, it will be hard to move compilation into the background in the future.
23:04:17  <devsnek>littledan: is the overhead of wasm optimization greater than the overhead of js optimization
23:04:25  <devsnek>just as a curiosity
23:05:56  <littledan>devsnek: Well, JS parsing and bytecode generation can be done during ParseModule, which can be done in the background, since modules are defer or async
23:06:31  <devsnek>an engine may need to readjust the bytecode depending on the values of imports
23:06:42  <littledan>Often, Wasm modules are extremely large, making them take a while to load up. That's why engines have been investing in baseline compilers.
23:06:55  <littledan>I don't think this comes up in JS the same as it does in Wasm
23:07:18  <devsnek>alright