2024-03-01 [05:51:22.0891] (I don’t have a real position one way or the other on undefined/null; was not trying to make a particular argument about which should be used where) 2024-03-05 [14:39:13.0934] interesting feedback on observables from the W3C TAG: https://github.com/w3ctag/design-reviews/issues/902#issuecomment-1942576159 [14:39:51.0337] Is anyone interested in discussing Observables in TC39, as Lea recommends? [14:59:00.0815] ljharb was definitely interested in seeing it go through TC39 IIRC [14:59:36.0996] (I'm neutral on venue in theory, but it'd be good to have *a* venue where discussions can take place.) [14:59:53.0654] i'd like to first be convinced that a discussion would be productive [15:00:45.0722] it is a thing we have already discussed in the past [15:00:58.0673] literally no one has brought it to committee since 2016 [15:01:25.0973] wasn't abortcontroller the sticking point back then too? [15:01:37.0258] It was very much not shot down at that time [15:01:47.0963] i see [15:01:50.0314] a version was created which was based on the concurrent TC39 cancellation version [15:01:57.0099] which was also not shot down, just withdrawn by the champion [15:02:43.0349] i am not opposed to discussion provided that we first agree on goals, since the champion in this case already chose to not bring this to tc39 [15:02:46.0997] I think we have had significant cultural problems that led to this demotivation, and we're not perfect, but I'd say it was definitely worse in 2016 [15:03:23.0451] given that we cannot force it to be under tc39 purview, what is the goal of the discussion? is it design feedback? is it like a resolution to try to convince the champion to bring it to tc39? [15:04:54.0859] well, the purpose of me raising it in this current discussion was, "hey, we care about the TAG thinks, they had a recommendation for us, what should we do" [15:05:08.0509] we'd kinda need a stronger goal set for a TC39 discussion, I agree [15:06:24.0151] as far as convincing people, in my conversations with Ben Lesh over the years, he was always happy in principle with this going to TC39, just skeptical that we could get our act together and deliver on anything (so I was unable to convince him to do the work to make it happen in TC39). This does point to a serious problem of ours. [15:07:56.0782] agreed [15:08:14.0360] on the merits alone i think i actually disagree with lea's feedback [15:08:22.0162] interesting, how so? [15:08:53.0683] my sense has been that there will be no concrete users of the API in ecma262, so we'll be designing an interface that's constrained by the web APIs that need this [15:09:25.0571] so doing in 262 adds more friction given the amount of tight coupling that needs to happen during the design anyway [15:09:31.0481] * so doing it in 262 adds more friction given the amount of tight coupling that needs to happen during the design anyway [15:09:39.0963] also more layering juggling [15:09:49.0416] we regularly take web API design constraints into account in TC39. Conversely, that proposal repo doesn't show much activity from a variety of web folks as you'd hope for. [15:10:29.0274] so the purpose of standards venues is often to bring people into discussions. TC39 might be a good or bad tool for that, depending on the details. [15:10:41.0555] sure [15:11:30.0754] still that's why i don't think tc39 is a good fit. i'd rather not design a pure interface that already has real world constraints, where those real world constraints are somewhat far away from us [15:12:30.0940] honestly for this particular API, the stuff I'm more worried about design-wise is all the weird combinators people end up wanting in RxJS, and is it a problem that this lacks those and goes for something cleaner. This doesn't really have to do with anything that the web platform *or* TC39 have thought very much about. [15:13:00.0641] i'm not really aware of that concern and that may change my thinking [15:13:23.0261] the constraints here with the web platform are really really simple, just like "it has to be sync enough that I can do preventDefault", not much more [15:13:35.0694] abortcontroller...? domerror? [15:13:40.0436] also like "there has to be a concept of unsubscribing, and also dropping events if they come too fast" [15:15:05.0072] so, yeah, if we say that all unsubscribing is owned by the web platform because of AbortController, I guess. But we can just as much make a new "subscription" object that has a [Symbol.dispose] method (this would be more similar to how RxJS works today, I think, so it's more proven out that it works) [15:15:46.0558] sorry what is the DOMError part? that seems more like an effect of venue choice than motivation [15:17:31.0489] > <@littledan:matrix.org> honestly for this particular API, the stuff I'm more worried about design-wise is all the weird combinators people end up wanting in RxJS, and is it a problem that this lacks those and goes for something cleaner. This doesn't really have to do with anything that the web platform *or* TC39 have thought very much about. Fascinating data which could inform this: https://github.com/WICG/observable/issues/106 [15:47:19.0838] > <@shuyuguo:matrix.org> my sense has been that there will be no concrete users of the API in ecma262, so we'll be designing an interface that's constrained by the web APIs that need this I'm not sure why you would think this. Promises are widely useful in Node, and Observables are, to a first approximation, just a bunch of Promises. UI-driven event streams are the *obvious* primary use-case for them, and that's *mostly* a browser thing as a result, but not entirely, and there are plenty of other uses (literally anything that currently relies on a callback that's invoked multiple times asynchronously). 2024-03-06 [16:28:46.0202] there weren't any uses of Promises in the language when they were first added [16:29:41.0578] yeah but there was an obvious thing they would be used for, i.e. async functions [16:29:51.0866] is there a thing we even plausibly think Observable might get used for, in the language? [16:30:17.0903] (I'm not opposed to putting it in TC39 anyway, I just don't know of anything in the language that would need it) [16:35:59.0584] (I do agree with the point about it being shaped mainly by web constraints and so making more sense in WHATWG, unless there is some language-level thing we want it for) [17:06:48.0466] I don't understand this line of argument; what is the language-level thing that Temporal is for? [17:07:03.0317] all of the integrations I've heard of are at the web level, or other embedders [17:07:32.0950] * all of the integrations I've heard of for Temporal are at the web level, or other embedders [17:08:49.0112] I'd argue that either venue is valid, and we're in a situation of actual competition, for who can be the most helpful in facilitating discussion, decision-making, implementation, etc. [17:11:49.0623] I don't mean competition in the sense that we are against each other, but that we may decide to make ourselves more attractive, and this will lead to people choosing us as a venue to do work. [17:32:11.0271] > <@littledan:matrix.org> I don't understand this line of argument; what is the language-level thing that Temporal is for? It isn't specifically for anything in JS or the web platform, so it could work in either venue. things which are designed specifically for use in some other JS thing should be in JS; things which are designed specifically for use in some web platform thing should be in the web. (very weak senses of "should" in both cases.) [17:33:03.0734] this makes sense. so, how should we test, when analyzing a proposal, what it's "for"? [17:33:36.0600] (just for example, an important consideration for Observables is that running on the next microtask tick is too late to call `event.preventDefault`, which is the sort of consideration more likely to get surfaced / attended to in WHATWG.) [17:34:23.0313] (not to say that will necessarily decide the design, just that it's not a consideration which is central to TC39.) [17:35:10.0285] being synchronous is really important; it also comes up for signals. I feel like, given that we have promises, as well as lots of parts of module loading, TC39 just has to be able to reason about what's synchronous and asynchronous, and take requirements from its host environments for that. [17:35:47.0024] not saying things have to happen in TC39, just that we really need to be capable of reasoning about this, and not dismissing arguments about these requirements [17:36:05.0268] * not saying all related features have to happen in TC39, just that we really need to be capable of reasoning about this, and not dismissing arguments about these requirements [17:36:13.0514] anyway, so, I think most proposals aren't necessarily "for" anything in particular. Promises were for async functions, and Observables (IIUC) are for events. A lot of web stuff is sort of "obviously" for the web. AbortController was built for `fetch` but is useful broadly, and is a good example of how picking venue based on the immediate need can be bad (contra everything else I'm saying here) [17:37:26.0977] in the absence of other constraints, most general purpose computing things should be in JS, IMO - for example, I think it's silly that TextEncoder is in the web platform, and am glad we're getting base64 in JS [17:38:25.0616] so the question is, to what extent are Observables a general purpose thing, vs being mainly for events? and I guess that depends on your perspective. I know a lot of people like observables for general purpose computing. personally I expect 99%+ of my use of them will be events. [17:38:40.0749] yeah I agree that it would make sense for a feature which is supposed to be providing mostly better usability for events as part of DOM, and that is one possible direction for Observables. Definitely not the original one, though. [17:38:49.0185] * yeah I agree that it would make sense for a feature which is supposed to be providing mostly better usability for Events as part of DOM, and that is one possible direction for Observables. Definitely not the original one, though. [17:39:57.0727] the direction that Lea is suggesting is more broad (general pub/sub). Also the original direction is more broad (generalizing Promises!) [17:40:51.0441] honestly I'm kinda scared of non-trivial usages of Observables, and yeah the trivial usages are more like making events nicer [18:18:03.0716] One thing that I’m a bit afraid of is that we’ll have two separate “values over time” abstractions on the web in the end with different APIs. I’m not sure that’s still fixable but having both at TC39 at least means there may be a little more consistency between them..? [18:26:30.0527] Are observables a value over time construct? I thought not [18:35:17.0374] To be clear: I meant “(multiple) values, over time”. Not a single logical thing over time (~reactive value like signals). [18:36:35.0981] More concretely: there’s observables and async iterators. Both can be used to “subscribe” to a stream of values that may be delivered asynchronously. They aren’t interchangeable but I believe they overlap in terms of usage and patterns. [19:20:09.0936] there's definitely overlap, but push-based and pull-based systems are different enough for there to be room for both, I think [19:21:03.0056] and don't forget web streams, for a third abstraction! which are kind of a mix of both push- and pull- [19:23:54.0531] this is a good time to reference's Kris Kowal's https://github.com/kriskowal/gtor [19:23:57.0972] * this is a good time to reference Kris Kowal's https://github.com/kriskowal/gtor [19:28:56.0087] I agree that both may be necessary to coexist. My concern is more that if both need a way to map/filter/reduce/mapParallel/etc, they may be more likely to end up with arbitrarily different APIs for those concerns if they are worked on in different venues [19:31:16.0083] Many people do appreciate the pull/push/hot/cold distinctions but I’m not sure casual users would understand why this two seemingly similar things have “random” inconsistencies. [19:54:57.0939] * Many people do appreciate the pull/push/hot/cold distinctions but I’m not sure casual users would understand why these two seemingly similar things have “random” inconsistencies. [03:24:17.0245] > <@jkrems:matrix.org> I agree that both may be necessary to coexist. My concern is more that if both need a way to map/filter/reduce/mapParallel/etc, they may be more likely to end up with arbitrarily different APIs for those concerns if they are worked on in different venues Well, the current observable proposal tries hard to unify with iterator helpers despite being in a web venue (at the expense of skipping important/confusing functions like switchMap). This is just an area where it is necessary to coordinate with both sides. Fortunately both TC39 and web standards folks have gotten better at this coordination over time. [04:37:01.0460] One risk is later additions for one not being mapped to the other side. Where I have seen this happen in the past, it is less about an information gap and more about different priorities of different groups of people, resulting in an inconsistent experience for web developers in the end 2024-03-07 [15:59:24.0867] shu: is it bad to set maximumByteLength to the max value? [15:59:45.0142] * shu: is it bad to set maxByteLength to the max value? 2024-03-08 [16:27:09.0666] i mean...... yeah? [16:27:13.0124] what's "bad" to you [16:29:09.0758] like do you care about running on 32-bit devices with smaller address spaces [17:01:47.0620] HIMEM.SYS or bust. [17:21:31.0306] > <@shuyuguo:matrix.org> what's "bad" to you like if implementations are allocating the entire thing up front like a Vec::with_capacity call that would be bad [17:21:40.0657] > <@shuyuguo:matrix.org> what's "bad" to you * like if implementations are allocating the entire thing up front like a Vec::with\_capacity call, then it would be bad [17:21:55.0121] i can only speak for chrome, and we just reserve the address space [17:21:58.0076] but if they're doing a virtual allocation its probably fine [17:22:33.0831] maybe we should put some guidance in the spec and in mdn [17:22:40.0102] > <@kriskowal:matrix.org> HIMEM.SYS or bust. don't tempt me [17:22:43.0517] the spec has guidance [17:22:49.0927] oh does it [17:22:57.0004] i must have missed it [17:23:16.0325] https://tc39.es/ecma262/#sec-resizable-arraybuffer-guidelines [17:23:27.0868] oh nice [17:23:33.0345] i was looking down by the constructor [17:24:26.0733] also https://tc39.es/ecma262/#sec-growable-sharedarraybuffer-guidelines [17:25:06.0125] i'll use `2**30` in my code then [17:25:16.0423] sorry microcontrollers [12:11:04.0911] any temporal experts around? https://users.rust-lang.org/t/the-state-of-time-in-rust-leaps-and-bounds/107620/10 [12:22:12.0821] well, that was decided way before I became involved, but here's my take: compatibility with the underlying host is the most prominent reason. UTC has no leap seconds, and Unix time tracks UTC. also interoperability; network hosts everywhere use UTC timestamps without leap seconds. if you constantly have to translate between 'JS time' and 'host time'/'network time' that seems like a distinction that most programmers will ignore, and therefore an opportunity for discrepancies to creep in everywhere. not to mention that it obligates implementations to include a table of leap seconds that they must keep up to date, like the TZ data [12:22:28.0772] maybe someone who was there at the time can give more info [13:31:25.0869] "UTC has no leap seconds"? UTC is precisely the time standard that *has* leap seconds. [13:37:04.0089] Unix time buries its head in the sand and pretends they don't exist, requiring OS's to either add a discontinuity, or smear the leap second across many seconds [13:37:18.0809] upi [13:37:48.0903] * you're right. sorry, I got confused with POSIX time. network time is POSIX time 2024-03-20 [06:23:27.0521] Is it intended that OrdinaryCreateFromConstructor is never called with a prototype from another specification? I'm looking back at https://github.com/WebAssembly/spec/issues/1549 in the context of whether the same issue is relevant to WebIDL DOMExceptions as well https://webidl.spec.whatwg.org/#js-DOMException-specialness. That is, should I be allowed to call OrdinaryCreateFromConstructor with another specification's name of an intrinsic object (violating the the assertion in step 1) [08:56:14.0794] akaster: you should not call things in a way which violates assertions, as a rule [09:00:00.0797] I guess it is not totally clear whether built-in objects from other specs count as "intrinsics" so it's not clear whether it would even make sense to do so, given the "realm's intrinsic object named intrinsicDefaultProto" step [09:02:02.0732] that issue asks if it is the intent of 262 for "Error"s to be a closed set, and I can at least answer that one: it is not [09:02:29.0505] OrdinaryCreateFromConstructor wasn't really designed for use in other specs but you can certainly do the things it does yourself 2024-03-22 [05:40:26.0861] ``` label: export let x = 1; ``` should ASI apply in this case? Babel, V8 and SM all agree on "no", but I cannot figure out why from the spec [05:40:32.0139] * ```js label: export let x = 1; ``` should ASI apply in this case? Babel, V8 and SM all agree on "no", but I cannot figure out why from the spec [05:41:31.0728] Ignore me, I just had to read past the ASI bullet points [05:41:32.0726] > a semicolon is never inserted automatically if the semicolon would then be parsed as an empty statement