TC39 Delegates
2025-09-23
plaintext logs
prev next
source on github
03:14
<James M Snell>
Promise pipelining is definitely something I'd like to explore further if there's interest. Right now we're accomplishing it using Proxy objects in which every property on the object is mapped as a promise. It's fairly elegant but does have it's own challenges.
03:46
<Mathieu Hofman>

I definitely would like to have an extended conversation on this, having built a system where we extensively do RPC and pipelining.

Notably, we prefer keeping explicit async operations (avoid . notation for eventual sends).

We have also effectively given up on using native promises for eventual results for now as it's not currently feasible to track promise adoption. I do however have some ideas around a proposal for an API that could be used by RPC libraries to detect when a promise it created adopts the state of another promise it has access to. Unsurprisingly this requires that the engine performs native promise adoption, and changes how reactions are handled (similar to some of the faster promise adoption proposal approaches)

05:35
<Mathieu Hofman>
Is there any preliminary idea of the schedule for next year's plenaries? Mostly looking whether there will be any January meeting
05:51
<ljharb>
there's usually a meeting in every odd month
09:58
<Rob Palmer>
I'll try to get you an answer by the end of this week, Mathieu.
15:11
<nicolo-ribaudo>
I don't know much about this topic so maybe it's a weird question, but is this observable in any way from JS code? Or is it just about providing guidance to implementations about some semantics that are already defined?
15:13
<bakkot>
I appreciate the clarity of this presentation for those of us who do not have the knowledge of other calendar systems
15:20
<Aki>
Don't forget your summary/conclusion and also if you dictate it, make sure to check it for clarity afterward like you would any other transcription
15:41
<Richard Gibson>

it is observable at least in serialization of Temporal.MonthDay instances: https://tc39.es/proposal-temporal/#sec-temporal-temporalmonthdaytostring

for example, visit https://tc39.es/proposal-temporal/docs/ and see the varying reference years for Hebrew calendar month–days:

["M05", "M05L"].map(monthCode => Temporal.PlainMonthDay.from({
  calendar: "hebrew", 
  monthCode, 
  day: 1,
}).toString())
// => ['1972-01-17[u-ca=hebrew]', '1970-02-07[u-ca=hebrew]']
15:41
<nicolo-ribaudo>
ty :)
15:50
<nicolo-ribaudo>
Nobody wants Promise.anyKeyed/Promise.raceKeyed right? Since Promise.any(Object.values(..)) is not bad to write
15:51
<ljharb>
if it's not producing multiple results then there'd be no value in a keyed variant, yes
15:51
<ptomato>
yes, the reference year is serialized in toString
15:52
<nicolo-ribaudo>
A Promise.raceKeyed method that returns an object with one property that has the resolved value, and all the other are still set to pending promises! :P
15:52
<Chengzhong Wu>
are these pending promises handled? or unhandled?
15:53
<bakkot>
I have unironically wanted this very often
15:53
<bakkot>
though the shape I want is something like, select(arrayOfPromises) which returns the first to settle and removes it from the array
15:55
<bakkot>
(in practice I think this is best done as an AsyncIterator, https://github.com/tc39/proposal-async-iterator-helpers/issues/15)
16:01
<kriskowal>
Also noteworthy that, to reduce attack surface, not every JavaScript environment should provide a file or HTTP I/O capability to every module, but should be able to import static assets from its own package.
16:01
<kriskowal>
Ah, heck, I’ll put that on the record.
16:16
<nicolo-ribaudo>
Chris de Almeida Kevin clarified the " NRO: I proposed "accept both in existing cases" thinking of ecma402 but we are actually only deciding for 262? " question
16:17
<nicolo-ribaudo>
It can be deleted :)
16:24
<bakkot>
can I get a stamp/merge on https://github.com/tc39/how-we-work/pull/165 ?
16:28
<nicolo-ribaudo>
Fun fact: I once had to explain to a bank that "you released a bug in Babel, and it immediately broke our frontend because it was in our semver range" is not exactly something that they should say without being ashamed
16:38
<bakkot>
re: js has the best sandbox of any language: wasm is much more sandboxed! depends on what you mean by "language" though I guess
16:38
<Chengzhong Wu>
human writable language
16:39
<Andreu Botella>
i've known people who write WAT
16:39
<bakkot>
I write WAT...
16:45
<Ryan Cavanaugh>
Why does it matter if code can detect if it's in the sandbox?
16:49
<Ashley Claymore>
is it the VW issue? car passes during tests. fails on the road.
16:51
<nicolo-ribaudo>
I feel like we'll need a continuation for this topic
16:53
<bakkot>
I think a good rule of thumb is that your timebox should have more minutes than you do slides
16:53
<nicolo-ribaudo>
I usually do 2x of the slides time
16:53
<Zb Tenerowicz (ZTZ/naugtur)>
detecting the sandbox and changing behavior is a minor issue, but the main issue Kris was talking about is sniffing what the host on the outside is
16:54
<Zb Tenerowicz (ZTZ/naugtur)>
We did that last time and still ran out :) This one is an update and an invitation to talk a lot more under less strict time constraints
16:55
<Zb Tenerowicz (ZTZ/naugtur)>
We'll want to make time for all of the feedback and questions. the more the better
16:55
<nicolo-ribaudo>
You are already past the timebox
16:55
<nicolo-ribaudo>
It was 30 min
16:56
<Zb Tenerowicz (ZTZ/naugtur)>
yup, not enough rehearsing
17:03
<dminor>
Kris Kowal: please add a summary / conclusion to the notes.
17:07
<Olivier Flückiger>
Another meta comment for the presentation: I had Compartments not paged in and no access to the slides beforehand, so I could not follow the second part.
17:32
<kriskowal>
Also, at the risk of missing the spot right between tedious and respectful, I think many voices have been using Lawrence Olivier as our reference for your name, but for the final -R should we be shooting for a German or a French R?
17:33
<kriskowal>
As for rushing the finale, I expect to be better prepared for next plenary. Apologies for the sudden appearance of slides and the explainer that has not yet caught up.
17:42
<Olivier Flückiger>
No worries, use the R that's easy for you :) Or call me Oli, as many people do
18:01
<Chris de Almeida>
please help with notes 🙏
18:04
<Rob Palmer>
Chris is bringing out the big guns here to get notetakers 😺
18:07
<Chris de Almeida>
he is misbehaving...scratching on doors
18:07
<ljharb>
wait, what's the german R?
18:07
<Chris de Almeida>
the perils of a new feline
18:07
<waldemar>
Is there something going on with the github spec change previews? I keep getting reviews where the preview generated for a PR shows unrelated changes as differences but doesn't highlight the changes made in the PR I'm reviewing.
18:08
<ljharb>
we just merged what was supposed to be a fix; but it's possible that it's still not working correctly
18:09
<bakkot>
by "the preview generated" do you mean the diff in github or the rendered specification?
18:09
<waldemar>
The rendered spec. It seems unrelated to the diff.
18:10
<waldemar>
Here's an example: https://github.com/tc39/proposal-amount/pull/69
18:10
<bakkot>
That's a rendering of the full spec including the diff, not of the diff itself.
18:11
<Jesse>
ah, that's not using the official spec generator thing; that's something specific to amount (cobbled together from various bits and pieces I found)
18:11
<Jesse>
(my understanding is that we're working on having an "official" solution to generate PR spec previews)
18:20
<ljharb>
i'm not sure if anyone's working on anything for proposals, to be clear
18:23
<Jesse>
oh, my misunderstanding, sorry
18:23
<bakkot>
https://github.com/tc39/template-for-proposals has a thing for generating previews; I don't think there's a plan to do anything else
18:23
<Jesse>
(might be cool to work on something like that and add it to the proposal templte fwiw)
18:24
<Jesse>
ah maybe I just wasn't using the tools in front of me
18:24
<Richard Gibson>
you probably cloned template-for-proposals before that was merged
18:24
<Richard Gibson>
but you can just copy it directly, as was done for e.g. https://github.com/tc39/proposal-immutable-arraybuffer
18:25
<bakkot>
Mathieu Hofman: re "compartments does give you that property when coupled with lockdown" - only if you carefully remove all the powerful globals from the compartment, right? because my understanding was that the default was to copy all of them
18:25
<Richard Gibson>
example result: https://github.com/tc39/proposal-immutable-arraybuffer/pull/58#issuecomment-3303583355
18:26
<nicolo-ribaudo>
The question is not how to see the rendered PR as a diff on top of ecma262, but how to see the rendered PR as a diff on top of the main version of the proposal
18:28
<Richard Gibson>
I wonder if you can use https://github.com/tc39/ecma262/issues/1891
18:31
<Richard Gibson>
I also wrote https://gist.github.com/gibson042/180b7147f84e17e4d55d2893f28719a2 in response to a comment from eemeli , which is heuristic rather than formally sound but can be used for arbitrary a/b ecmarkup diffs
18:41
<Mathieu Hofman>
I think what is included in the compartment's global by default is up to debate. I actually believe one the latest idea is to only include the undeniable global intrinsics by default.
18:42
<bakkot>
So... then you can't really run ~any third-party dependency, right? Most of those are going to use Map or whatever.
18:52
<keith_miller>
Chris de Almeida: I have to go to another meeting in 12 minutes is there any chance I can move my topic up?
18:53
<Chris de Almeida>
best I can do is ask the presenters if they want to prioritize any topics. we only have 6 mins left
18:54
<keith_miller>
Ah, ok I didn't realize there were only 6 minutes left
18:56
<kriskowal>
Regardless of whether you come up, we want to hear from you and will reach out.
19:07
<Mathieu Hofman>
What I referenced were the potential minimal default globals of a new Compartment. A system to handle and isolate dependencies built with compartments can rely on analysis to generate a policy listing which globals that particular dependency might need. As the creator of the compartment, its own default logic might be to always endow globals like Map and Set (even if not explicitly listed in the policy)
19:11
<Chris de Almeida>
we need a volunteer to help w/ notes for the rest of this session: <38 mins remaining
19:32
<nicolo-ribaudo>
Could a large website still adopt lockdown, if inside a shadowrealm?
19:33
<Zb Tenerowicz (ZTZ/naugtur)>
it sure could
19:34
<Rob Palmer>
I don't think anyone has countered the use of global coordination within isolated/modular containers
19:41
<Mathieu Hofman>
I don't think anyone has countered the use of global coordination (lockdown) in newly built applications either.
19:42
<ljharb>
what a spicy question mathieu
19:42
<rekmarks>

ljharb: to your reply to my topic, I'm not at all expecting "the way things are done" to go away, and essentially agree with your comment as captured in the notes:

If we make something good enough, then certainly the preponderance of users might migrate to it or use it for old things and the old things will never go away and humans don’t seem to have a great track record with migrating en masse from the crappy thing to the better thing.

19:43
<kriskowal>
I think the implied reach of this presentation greatly exceeds the specific complaint. If we frame this as a question about whether we have a choice between solving a specific problem with or without a mode-switch, we should make it work without the mode-switch so that the top 10k can benefit, and for that I agree. As a matter of opinion, I reject the literal interpretation categorically.
19:43
<ljharb>
my reply was more to the notion that "in 30 years surely everyone will have moved to the better thing", since reality largely disproves that on any reasonable timescale
19:44
<rekmarks>
What I meant to say was that "the preponderance of users might migrate to it, even though the old thing still exists and can't be ignored" 😛
19:46
<Rob Palmer>

https://almanac.httparchive.org/en/2024/javascript

4% of sites use the module script tag, 3.7% use dynamic import()

19:47
<Mathieu Hofman>
But the ecosystem has greatly benefited from this system existing. All new code is effectively authored with modules
19:47
<kriskowal>
Yes, and this statistic isn’t weighted by downloads.
19:47
<Rob Palmer>
Steve Jobs triggered a phase shift for Flash.
19:47
<ljharb>
it didn't need to exist as a runtime feature to provide an authoring benefit tho (which is why most of the people who author with ESM still transpile it to CJS for production)
19:48
<Mathieu Hofman>
they bundle to scripts for the web. A lot of code is running native esm in Node.js today
19:49
<Mathieu Hofman>
The web and Node.js benefit from running on a common authoring foundation
19:55
<ljharb>
maybe, but loading ESM in node is slower than loading CJS is, so in a perf-sensitive app they're likely to be building for node too.
20:06
<Mathieu Hofman>
is that an intrinsic limitation of ESM parsing ?
20:07
<bakkot>
I think if we were designing a system optimized for bundling and running in Node and similar runtimes we might well have made a number of different decisions (like making cjs interop easier) and that would have been better
20:08
<ljharb>
time will tell if it's intrinsic, but people worked really hard to make a fast implementation and this is the best we've got
20:09
<Andreu Botella>
I don't think there's anything about the way these large sites are developed that's intrinsic to the web – it's just large development teams and organizational boundaries
20:09
<bakkot>
and: I think if the purpose of the system was bundling and running in Node, we were the wrong body to be designing it (as evidenced by our failure to make the decisions optimized for those cases)
20:09
<Andreu Botella>
Rob was saying they made it work in Bloomberg with a large development team – sure, it's not the web, but that's not the part that matters
20:11
<bakkot>
as such, I think if in 2012 we had known that the ES module system was not going to be widely used on the web (which is not a foregone conclusion, even now, but supposing it was), then it would have been better for us not to build it, and to have it designed by different people who were better positioned to do that for the needs it would actually serve
20:21
<Zb Tenerowicz (ZTZ/naugtur)>
Apologies for taking more time than necessary with my last question. As a non-native speaker at 10PM I was doing my best to clarify what I mean and that's hard when my point starts with "I don't understand why"
20:22
<Mathieu Hofman>
I still believe that something needed to be done for the language itself, and that the ecosystem has benefited from having a solution specified at the language level as a coordination point so that most code is compatible with both web and non-web environments
20:26
<kriskowal>
We can be friends.
20:30
<kriskowal>
bakkot: I believe that at the heart of your talk, there is a very specific thing that you want that you can get without resistance: If there is a feature that is needed and beneficial to the most widely used websites in the world, that we should not entertain an implementation that is predicated on a lockdown-like mode-switch.
20:35
<Rob Palmer>
maybe, but loading ESM in node is slower than loading CJS is, so in a perf-sensitive app they're likely to be building for node too.
There's a chance import/export defer might change the balance for cases that use them. Because the module graph is explorable earlier than is possible with CJS, e.g. allowing concurrent parsing or proactive bytecode caching.
20:36
<ljharb>
that's a nice maybe :-)
20:46
<bakkot>
sorry for rushing you!
22:33
<James M Snell>
time will tell if it's intrinsic, but people worked really hard to make a fast implementation and this is the best we've got
Don't forget that there's a lot of backwards compat stuff in the mix there around the actual loading step in node. We run everything as esm in workers and don't see the same performance profile. It's not the best it could be but runtime cruft does add a fair amount of it's own overhead
22:34
<ljharb>
yeah in no way was i putting shade on node with that one; many aspects of the ESM design make it difficult to do performantly.
22:35
<James M Snell>
Heh, sometimes node needs shade