| 22:39 | <littledan> | interesting feedback on observables from the W3C TAG: https://github.com/w3ctag/design-reviews/issues/902#issuecomment-1942576159 |
| 22:39 | <littledan> | Is anyone interested in discussing Observables in TC39, as Lea recommends? |
| 22:59 | <bakkot> | ljharb was definitely interested in seeing it go through TC39 IIRC |
| 22:59 | <littledan> | (I'm neutral on venue in theory, but it'd be good to have a venue where discussions can take place.) |
| 22:59 | <shu> | i'd like to first be convinced that a discussion would be productive |
| 23:00 | <shu> | it is a thing we have already discussed in the past |
| 23:00 | <littledan> | literally no one has brought it to committee since 2016 |
| 23:01 | <shu> | wasn't abortcontroller the sticking point back then too? |
| 23:01 | <littledan> | It was very much not shot down at that time |
| 23:01 | <shu> | i see |
| 23:01 | <littledan> | a version was created which was based on the concurrent TC39 cancellation version |
| 23:01 | <littledan> | which was also not shot down, just withdrawn by the champion |
| 23:02 | <shu> | 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 |
| 23:02 | <littledan> | 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 |
| 23:03 | <shu> | 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? |
| 23:04 | <littledan> | 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" |
| 23:05 | <littledan> | we'd kinda need a stronger goal set for a TC39 discussion, I agree |
| 23:06 | <littledan> | 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. |
| 23:07 | <shu> | agreed |
| 23:08 | <shu> | on the merits alone i think i actually disagree with lea's feedback |
| 23:08 | <littledan> | interesting, how so? |
| 23:08 | <shu> | 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 |
| 23:09 | <shu> | so doing it in 262 adds more friction given the amount of tight coupling that needs to happen during the design anyway |
| 23:09 | <shu> | also more layering juggling |
| 23:09 | <littledan> | 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. |
| 23:10 | <littledan> | 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. |
| 23:10 | <shu> | sure |
| 23:11 | <shu> | 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 |
| 23:12 | <littledan> | 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. |
| 23:13 | <shu> | i'm not really aware of that concern and that may change my thinking |
| 23:13 | <littledan> | 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 |
| 23:13 | <shu> | abortcontroller...? domerror? |
| 23:13 | <littledan> | also like "there has to be a concept of unsubscribing, and also dropping events if they come too fast" |
| 23:15 | <littledan> | 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) |
| 23:15 | <littledan> | sorry what is the DOMError part? that seems more like an effect of venue choice than motivation |
| 23:17 | <littledan> | 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. |
| 23:47 | <TabAtkins> | 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 |