| 00:28 | <ljharb> | there weren't any uses of Promises in the language when they were first added |
| 00:29 | <bakkot> | yeah but there was an obvious thing they would be used for, i.e. async functions |
| 00:29 | <bakkot> | is there a thing we even plausibly think Observable might get used for, in the language? |
| 00:30 | <bakkot> | (I'm not opposed to putting it in TC39 anyway, I just don't know of anything in the language that would need it) |
| 00:35 | <bakkot> | (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) |
| 01:06 | <littledan> | I don't understand this line of argument; what is the language-level thing that Temporal is for? |
| 01:07 | <littledan> | all of the integrations I've heard of for Temporal are at the web level, or other embedders |
| 01:08 | <littledan> | 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. |
| 01:11 | <littledan> | 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. |
| 01:32 | <bakkot> | I don't understand this line of argument; what is the language-level thing that Temporal is for? |
| 01:33 | <littledan> | this makes sense. so, how should we test, when analyzing a proposal, what it's "for"? |
| 01:33 | <bakkot> | (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.) |
| 01:34 | <bakkot> | (not to say that will necessarily decide the design, just that it's not a consideration which is central to TC39.) |
| 01:35 | <littledan> | 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. |
| 01:35 | <littledan> | 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 |
| 01:36 | <bakkot> | 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) |
| 01:37 | <bakkot> | 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 |
| 01:38 | <bakkot> | 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. |
| 01:38 | <littledan> | 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. |
| 01:39 | <littledan> | the direction that Lea is suggesting is more broad (general pub/sub). Also the original direction is more broad (generalizing Promises!) |
| 01:40 | <littledan> | honestly I'm kinda scared of non-trivial usages of Observables, and yeah the trivial usages are more like making events nicer |
| 02:18 | <Jan Olaf Martin> | 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..? |
| 02:26 | <littledan> | Are observables a value over time construct? I thought not |
| 02:35 | <Jan Olaf Martin> | To be clear: I meant “(multiple) values, over time”. Not a single logical thing over time (~reactive value like signals). |
| 02:36 | <Jan Olaf Martin> | 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. |
| 03:20 | <bakkot> | there's definitely overlap, but push-based and pull-based systems are different enough for there to be room for both, I think |
| 03:21 | <bakkot> | and don't forget web streams, for a third abstraction! which are kind of a mix of both push- and pull- |
| 03:23 | <bakkot> | this is a good time to reference Kris Kowal's https://github.com/kriskowal/gtor |
| 03:28 | <Jan Olaf Martin> | 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 |
| 03:31 | <Jan Olaf Martin> | 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. |
| 11:24 | <littledan> | 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 |
| 12:37 | <littledan> | 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 |