00:30:37  * leobalterquit (Ping timeout: 255 seconds)
00:31:11  * leobalter_joined
00:41:04  * kesnequit (Read error: Connection reset by peer)
00:44:36  * AtumTquit (Quit: AtumT)
01:38:57  * cybaijoined
01:38:59  * cybaiquit (Read error: Connection reset by peer)
01:40:02  * cybaijoined
01:58:06  * keith_mi_quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
02:33:52  * keith_mi_joined
02:37:44  * hellauerjoined
02:56:02  * jwaldenquit (Quit: ChatZilla 0.9.92-rdmsoft [XULRunner 35.0.1/20150122214805])
03:11:43  * efaustquit (Ping timeout: 255 seconds)
03:12:31  * efaustjoined
03:12:55  * efaustchanged nick to Guest8616
03:18:54  * keith_mi_quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
03:39:28  * jmdyckquit (Quit: Leaving.)
04:18:32  * keith_millerquit (Quit: My Mac Pro has gone to sleep. ZZZzzz…)
04:49:36  * keith_millerjoined
06:25:42  * keith_millerquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
08:28:09  * mgoljoined
10:01:42  * hellauerquit (Ping timeout: 264 seconds)
10:03:54  * cybai_joined
10:06:30  * cybaiquit (Ping timeout: 264 seconds)
10:16:49  * hellauerjoined
10:17:36  * obensour1quit (Ping timeout: 244 seconds)
10:28:22  * hellauerquit (Ping timeout: 252 seconds)
10:29:35  * hellauerjoined
10:31:34  * cybaijoined
10:31:46  * obensour1joined
10:34:12  * cybai_quit (Ping timeout: 252 seconds)
10:55:42  * cybaiquit (Remote host closed the connection)
11:37:49  * kpattichajoined
11:45:34  * jmdyckjoined
11:51:50  * cybaijoined
12:06:49  * cybaiquit (Remote host closed the connection)
12:10:15  * cybaijoined
12:15:54  * gibson042quit (Ping timeout: 252 seconds)
12:55:37  * hellauerquit (Ping timeout: 250 seconds)
12:56:51  * hellauerjoined
13:00:30  * kpattich_joined
13:01:18  * kpattichaquit (Ping timeout: 245 seconds)
13:09:24  * gibson042joined
13:29:39  * hellauerquit (Ping timeout: 252 seconds)
13:32:09  * hellauerjoined
14:01:47  * kpattich__joined
14:03:22  * kpattich_quit (Ping timeout: 245 seconds)
14:47:33  * gibson042quit (Ping timeout: 245 seconds)
15:01:21  * cybaiquit (Remote host closed the connection)
15:01:40  * jmdyckquit (Ping timeout: 250 seconds)
15:02:56  * gibson042joined
15:03:04  * jmdyckjoined
15:13:41  * cybaijoined
15:18:13  * cybaiquit (Ping timeout: 246 seconds)
15:49:33  <mathiasbynens>ljharb: https://docs.google.com/document/d/101VnCaQaheEwSXQ_-eSAKpkutnAbDjS9T5TS2gF5zLQ/edit
15:52:09  <annevk>mathiasbynens: guess you shared that with wycats already?
15:53:12  <mathiasbynens>annevk: i believe gsathya did, yeah
15:57:55  <ljharb>mathiasbynens: that just talks about conceptually; is it quantified anywhere?
15:58:59  <ljharb>like let’s say my many-10Ks class-based react component codebase has a decorator on every one. How much startup cost increase are we talking? 1ms, 1s, 1m?
16:00:16  <devsnek>mathiasbynens: my question is, at the cost of adding all that weird syntax/behaviour in the new proposal, is the entire feature worth it
16:00:31  <devsnek>its basically adding a new DSL to the language
16:03:04  * jwaldenjoined
16:09:26  * kesnejoined
16:10:05  * keith_millerjoined
16:11:46  * kesnequit (Client Quit)
16:12:53  * kesnejoined
16:18:35  * kesne_joined
16:20:42  * kesnequit (Ping timeout: 252 seconds)
16:34:28  * Nimelrian_joined
16:43:03  <mathiasbynens>ljharb: the whole point of the doc is that you can't answer this question, even when given code which you can statically analyze
16:43:46  <mathiasbynens>devsnek: that's a good question, and one we should be asking ourselves more often
16:44:20  <devsnek>any solution that has to work with function hoisting is probably going to be meh
16:44:33  <devsnek>i'd assume "make decorated functions unhoisted" has been proposed at some point
16:48:17  <ljharb>mathiasbynens: ok so it could be negligible and this could all be fud?
16:48:50  <ljharb>while it could also be the worst case, but nobody knows how bad that might be
16:49:31  * keith_mi_joined
16:50:12  <ljharb>if the only way to answer it is an implementation, isn't that the purpose of stage 3?
16:52:01  <mathiasbynens>ljharb: i'm saying it depends on what the decorator does exactly, which you cannot statically figure oout
16:53:28  * cybaijoined
16:53:58  <mathiasbynens>imho it's not our job as implementers to do busywork for TC39. multiple implementers voiced concerns re: start-up performance AND implementation complexity, so the suggestion to "try and implement it to see how bad it really is" feels a little detached from reality
16:55:34  <ljharb>that's fair.
16:56:02  <ljharb>altho the complexity grows directly out of all the use cases, so i'm not sure that's avoidable, altho the performance part may be.
16:57:48  * kpattich_joined
16:57:57  * cybaiquit (Ping timeout: 245 seconds)
17:00:01  <mathiasbynens>yep, it's a trade-off for sure
17:00:18  * kpattich__quit (Ping timeout: 246 seconds)
17:01:15  * AtumTjoined
17:21:44  <Bakkot>we are not required to support all use cases; as such it's totally avoidable by saying "that use case requires too much implementation complexity and we aren't going to support it"
17:23:09  * mgolquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
17:23:47  <devsnek>+1 Bakkot
17:38:08  <ljharb>Bakkot: that is true; i should have said, not sure that's avoidable without cutting off a bunch of use cases
17:38:26  <ljharb>but also, many of the use cases not being met may cause objections to advancement.
18:06:12  * leobalter_changed nick to leobalter
18:06:49  * kpattich__joined
18:09:14  * kpattich_quit (Ping timeout: 246 seconds)
18:22:39  * mgoljoined
18:29:25  <littledan>What if top-level await were synchronous if an entire module subgraph is deterministically synchronous (does not contain any syntactic top-level await)? https://github.com/tc39/proposal-top-level-await/pull/61
18:29:44  * mgolquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
18:30:04  <littledan>so it's not "Zalgo" (like #49) but it's also not creating lots of trivial Promises and depending on queue flushes to work through them in time (like #51)
18:32:30  <Domenic>littledan: as you know I think we'll want to do queue flushes on the web anyway, so as long as that's preserved I guess whatever is fine for the top-level await spec.
18:49:26  * kesne_quit (Read error: Connection reset by peer)
18:50:56  * kesnejoined
19:00:22  * cybaijoined
19:01:23  * kpattich__quit (Remote host closed the connection)
19:04:17  * kesnequit (Read error: Connection reset by peer)
19:04:38  * cybaiquit (Ping timeout: 245 seconds)
19:05:33  <annevk>Domenic: is that a cross-browser pos? It makes sense to me btw, but wonder how many folks considered the tradeoffs
19:30:48  <littledan>Domenic: Yeah, this would be fine in conjunction with that
19:31:17  <littledan>Domenic: I don't think the difference between #61 and #51 would be observable in this case
19:41:25  * kesnejoined
19:41:48  <littledan>I think it'd be pretty weird to have the Promises set up in one layer (JS), and synchronization guarantees made in another layer (HTML for its microtask checkpoint), unless we have a very explicit contract that it's going to do exactly that. In this case, such a construction feels like overkill. What we want is for synchronous subgraphs to run in order--microtask checkpoints are one way of doing that, and just not adding in all
19:41:48  <littledan>these promises on synchronous subgraphs is another way (and perfectly compatible with adding other, independently motivated microtask checkpoints)
19:42:17  <littledan>anyway, you could think of it as an editorial change, if the web will end up doing these microtask checkpoints.
19:46:54  * Nimelrian_quit (Ping timeout: 258 seconds)
19:48:00  <annevk>littledan: so an argument for interleaving tasks as well is that module loading should still give opportunities for hitting 60fps
19:48:38  <littledan>annevk: Unfortunately, we heard from nyaxt on html#4400 that it'd be hard to yield to the event loop after each module load
19:48:54  <annevk>This does seem like it’d benefit from involving more people
19:49:41  <littledan>I think yielding optionally, driven by the UA, seems like a good proposal. However, it wouldn't address the specific synchronization need we have here. I think it'd be best to decouple these
19:50:06  <littledan>annevk: Is there someone from Mozilla who works on event loop kind of things who we could bring in?
19:51:13  <annevk>littledan: smaug and dbaron I suppose
19:51:46  <annevk>littledan: rniwa from Apple too?
19:54:52  <littledan>cc'd on html#4400
19:55:26  <littledan>I've been wondering about something crazier as far as being incremental: Should we let code start executing when the module graph is not all fetched and parsed?
19:56:45  <littledan>It would complicate things, but it could improve parallelism. On the other hand, you could accomplish the same though manual code splitting instead and give stronger priority hints to the browser that way
20:06:10  <Bakkot>grammar question: is `({ ...{a} } = {})` legal?
20:06:17  <Bakkot>note that this is assignment, not declaration
20:06:36  <Bakkot>oh wait no
20:06:47  <Bakkot>there's an early error for it, ok
20:06:51  <ljharb>Bakkot: i wouldn't expect spread without an identifier to be legal there
20:06:58  <ljharb>or rest, rather
20:07:33  * AtumT_joined
20:07:35  <Bakkot>Yeah, it has to be an identifier, not an object or array. Did not know that.
20:09:22  <Bakkot>lol, but `({ ...(a) } = {})` is legal; that's fun
20:09:56  <ljharb>that must bind to `a`?
20:10:03  * AtumTquit (Ping timeout: 245 seconds)
20:10:12  <ljharb>interesting, seems like a weird omission to allow parens there
20:10:20  <ljharb>since `var (a) = 3` doesn't work
20:10:34  <Bakkot>`(a) = 3` does
20:10:39  <ljharb>oh right
20:10:46  <ljharb>ok well then it's horrifically consistent
20:10:51  <ljharb>yay
20:13:34  <annevk>littledan: that sounds like defer or async
20:15:03  <littledan>annevk: Modules are always defer or async, but as a group. All of them are fetched and parsed before any of them run, and that fetching and parsing happens as defer or async
20:15:34  <littledan>As we think about HTML or CSS modules, I guess these problems become more acute. Suddenly more and more stuff is all at once
20:15:58  <littledan>Or, maybe it's not. Maybe those do their loading in the Evaluate phase, unlike JS. I'm not sure
20:20:43  * AtumTjoined
20:21:35  * AtumT_quit (Ping timeout: 244 seconds)
20:33:59  * kesnequit (Read error: Connection reset by peer)
20:41:15  * kesnejoined
20:46:55  <annevk>littledan: you mean that they would export a promise? I don’t think that’s how folks are thinking about them
20:49:07  * cybaijoined
20:53:58  * cybaiquit (Ping timeout: 268 seconds)
20:57:55  * keith_millerquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
21:02:40  * kesnequit (Read error: Connection reset by peer)
21:03:17  * kesnejoined
21:16:37  <littledan>No, I mean they might run via top-level await basically
21:17:13  <littledan>But if they pull in their dependencies this way, it would differ from JS. So I am wondering if JS should actually do this too
21:26:04  * keith_millerjoined
21:27:49  * Guest8616part
21:38:49  * keith_millerquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
21:48:28  * keith_millerjoined
21:48:51  <littledan>annevk: What I'd heard is that HTML modules might be asynchronous (as if they used top-level await), which could make sense as the HTML processing module is async. So would it make sense to extend that further, if JavaScript is what's making startup slow on lots of pages?
21:52:46  <ljharb>JS often needs to block startup tho, to set up the environment or the DOM or whatnot
22:04:19  * howdoiquit (Quit: Connection closed for inactivity)
22:10:08  * Fishrock123joined
22:14:08  * gibson042quit (Quit: Leaving.)
22:47:26  * cybaijoined
22:48:04  * hellauerquit (Quit: WeeChat 2.4)
22:51:50  * cybaiquit (Ping timeout: 250 seconds)
23:19:34  * keith_millerquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
23:19:49  * srl295joined
23:28:44  * kesnequit (Read error: Connection reset by peer)
23:37:34  * kesnejoined
23:57:49  * kesnequit (Read error: Connection reset by peer)
23:58:52  * kesnejoined