Ready to be worked on.

reassigned to Lea & Tess

Lea: Seems to have been validated by author pain points extensively, there are a ton of libraries for it. Does improve a part of the platform that does not currently have the best dx events. It does to events what promises did to callbacks. One minor point is I'm missing a discussion of how this compares to the xisting listener.. does add a property to event objects but doe sit have compelte parity with addeventlistener. Do authors still need addeventlistener for some things? I wouldn't immediately know how to do the same thing as the once option on addeventlistener. As a library author I'm missing discussion on how to create classes that leverage this in the best way. Right now if you want to create a library or a class in the best way that authors can listen to you have to create an event target which is suboptimal - I was wondering if this fixes that. Can library authors leverage observable so they don't have to extend event target. By looking at the explaienr I'm not sure. I can ask. Leaning positive.

Matthew: looks like someone is replying to something... the last comment is answers to questions asked previously, except I don't see those questions in this thread. The issue of really adding something new and different, or could this be duplicating stuff has come up. The things you specifically just highlighted haven't come up so I'd say it's worth asking.

Tess: Meta comment... I get worried when people are proposing a new feature whcih is a variant of an existing feature. We're doubling API surface. Two APIs which accomplish similar things might not be great. Counter example - xhr vs fetch - we couldn't adjust xhr to get to the future we wanted. It's an instructive example. The other concern I have is we can't get rid of the old thing. We can add this new thing which is a variant of the old thing, but it's critical when we do that kind of thing that the old thing and the new thing are defined in terms of a common model so it's clear how they relate and how they interoperate and hook into the underlying platform. If you don't do that you end up in a world of pain. We have enough pain on the web platform. The example from the past is the portal element... a variant of iframe... Maybe they've done all of this work. This is my gut reaction. The benefit of the new thing needs to be worth the cost of the api surface duplication. Maybe the answer is that they've done it and it's great.

Peter: this feels more like a wrapper around events. They're not replacing events, they're polishing the api surface for dealing with them. Which is fine. How does it work with once - my guess would be it's not designed to, this is for things that are going to happen over and over.

Lea: the once option in addeventlistening is not about things that only happen once, only things you want to listen to once. Shorthand to having a listener that you then remove

Peter: that's what I meant. If you only care about it happening once, why would you build an observable? It's not replacing a one time event listening, but something you want to be reacting to over and over

Lea: the idea that it has filtering built in... it seems to have a lot of quality of life improvements.. you might want to only listen once but only have all the filtering of targets and all of that that it supports

Peter: raises the question - do youw ant to keep listening until you find something that passes your filter, or just ignore if it doesn't..

Lea: use cases for both. Another concern - it seems that this is meant to be standardised in a venue that is not tc39. For something like this... we don't want to repeat the abort signal and abort controller situation. This should live on tc39. Kind of a problem that WHATWG is adding primitives that should live on ECMAScript.

Peter: this went through tc39 in the pat and was rejected.. but not necessarily in this form

Lea: what were the reasons? They might apply. addeventlistener carries a lot of baggage. This api should definitely have primitives that work together with existin events, but it should be independant of the DOM. Right now the only solution we have is that we can extend event target to apply to objects unrelated to the DOM. .... No question that the user need is there, but question is this the best solution.

Tess: about the venue .. also relevant

Peter: ... or are they purely one off? Also promises made thing scomposible.. also meant async and await to hide complexity but give all that power in a simple way. Does this have a similar path?

Tess: really highlights the importance of the venue concern. If this is a stepping stone towards a js language feature it really needs to be tc39..

Lea: worth trying to get right and not just ship something to be done with it. An observable designed well is something that will be used for decades. Should be done by the right venue. They do have a section about standards venue.

Tess: lots of interesting thoughts.. let's post lots of interesting comments.

Lea: has anyone been in contact with TC39?

Yves: I don't see any particular signal...

Lea: I can ping some TC39 folks and ask...

Yves: would be good to know if there are outstanding issues from their sides...

Lea: no webkit standards position... at least 3 tc39 folks have "thumbs-uped" my comment...

Yves: the comment on the webkit standards position - discussion between Anne and Dom ... discussed the idea of bringing this to a TC39 group.. a discussion in progress... https://github.com/WebKit/standards-positions/issues/292#issuecomment-2177303724

Peter: a whole section in their explainer about standards venue...

Hi @domfarolino,

We looked at this today during a breakout. We do have consensus on most of the concerns I expressed above, especially around standards venue.

Furthermore, we had some questions about the API shape that we couldn’t figure out from the explainer, and we were hoping you might be able to clarify.

It seems (though we are not 100% certain) that this is a separate primitive than EventTarget and simply integrates with it. If that is correct, the current explainer is a little unclear on what the boundaries of each are. Does it use the same Event objects? Does it register event listeners behind the scenes? How does bubbling work? Does it support bubbling to parent objects when not using the EventTarget integration?

• All examples are about listening to predefined events on existing objects. How do authors create objects that can emit events? Today they need to extend EventTarget which is suboptimal. Does Observable enable a new pattern for this?
• Do you folks have any plans to integrate with any of the other pub/sub mechanisms on the web platform or JS runtimes? E.g. all the *Observer objects, or Node’s Event emitter?
• While the code examples are certainly succinct, we had trouble figuring out how many of them worked and extrapolate how to write code about use cases not listed in the explainer. We were especially unclear on the arguments of subscribe() (what does next do? How does it differ from callback?)

We think a reworking of the explainer would really help answer these types of questions. Some (non-exhaustive) suggestions:

• Start from use cases and user needs.

• Include some simple code examples before the more pragmatic ones, so the reader can understand how the primitives involved work

• Include code showing how authors can use this to enable their own objects to emit events.

• A clear separation of what is Observable and what is EventTarget.

@littledan @ljharb @ctcpip @robpalme We saw you folks upvoted my last comment. Has there been any recent discussion in TC39 around this? Any plans to discuss it in the upcoming Plenary?