Domenic Feedback

[pemrouz]

Very productive meeting with @domenic and lots of great feedback.

• First-class integration with Promises from ground up seems promising vs tacking some promise-returning functions, especially in overcoming challenges with Observables/DOM integration.
• Useful to keep all material to show research into cross-cutting concerns done, but we should focus on making this Observables take 2, the platform's push-based primitive
• Defining lifecycle via subclassing won't work with privates (currently using static), there's no protected in JavaScript. Between class-based and constructor function to configure, constructor is preferable.
• Useful to ergonomically convert at boundaries (i.e. as we accept iterable/async iterable right now), but shouldn't unify too much across the push/pull axis.
• Functional approach may be popular, but at odds with the traditional approach i.e. we should use methods instead
• In relation to Iteration Helpers proposal, that would be pull, this would be push. Each could add additional, separate API that makes sense to both as well.
• We can defer releasing library until we want to go from Stage 2 to 3.

[domenic]

We can defer releasing library until we want to go from Stage 2 to 3.

I want to amend this a bit. I think a crucial part of getting stage 2 (i.e., commitment that this should be in the language) is signs that this method gets high adoption, comparable to existing libraries, and that TC39 isn't pushing through something that the community is uninterested in. So I think it should be released during stage 1, and high adoption for the library will be a stage 2 prerequisite.

[ghermeto]

I would like to have a polyfill available before next meeting, but high adoption seems extremely high bar for reaching stage 2. Are there other examples where that was a requirement for stage 2?

[domenic]

Observables.

[ghermeto]

thanks! And since both proposals have similarities, I think it is fair.

[littledan]

As we discussed in TC39, I don't think it's a reasonable requirement to ask that the adoption be the same as existing libraries. We don't seem to be asking for this in other ongoing standard library efforts:

• TC39 is developing Temporal as a new Date library. I don't anticipate that adoption will be as high as Moment or date-fns for a while; nevertheless, the committee advanced it to Stage 2.
• Work is ongoing on the kv-storage built-in module, but I don't see discussion in the issue tracker about blocking this on its popularity surpassing storage libraries.

(Observables never advanced to Stage 2, but there were multiple issues other than "lack of ecosystem adoption" that held it back.)

It may be better to wait a bit to widely popularize a library, so we still have latitude to change it as we continue to get feedback.

[domenic]

I think we may be talking past each other.

• Temporal advanced because the moment authors stated they would be able to base their library on top of it. I would similarly like to see such statements from popular event/observable libraries or ecosystems for emitter.
• KV Storage is actually taking the exact path I'm recommending; it was only developed as a built-in module after existing storage libraries (notably localForage) had already proved that the API shape worked.

I am worried about emitter introducing a new unproven pattern and API shape to the ecosystem, with no commitment from ecosystem members to base themselves on top of it. If we can get ecosystem acceptance at the same level as KV storage's API, or commitment from popular event libraries (like RxJS or the DOM) to base themselves on emitter, then we're in a better place to consider this as something to be "eventually included in the standard".

[littledan]

I think the idea here is to do something broadly similar--that Emitter would be designed to meet many of the usage patterns of Observable, without being exactly the same API. This is analogous (but maybe greater in degree?) to how kv-storage doesn't use the same method names as localForage, or how TC39 Promises have some semantic differences from jQuery Promises. I agree that it will be important to work with the existing Observable library maintainers, so I'm encouraged that this conversation has already begun in #7 .

[syg]

I second that high adoption of a library is not a reasonable or a desirable bar here as a stage 2 entry criterion. The approach here is as @littledan lays out: this is a synthesis of prior art in other languages, as well as existing JS libraries, proposals, and common feedback about them.

Collaboration with existing event library authors and other folks in the ecosystem is definitely reasonable.