TC39 Signals
2025-04-16
plaintext logs
prev next
source on github
18:47
<jschoi>

I’ve been excitedly watching both ES Signals and WHATWG Observables from the outside. And I’m enthused about tomorrow’s presentation for plenary feedback from Dominic Farolino about WHATWG Observables (https://docs.google.com/presentation/d/1i5_zneksrU7i7ZHcl5EQRzUHGkmXRIQKd-bLfrPRNXY/edit?usp=sharing).

As a heads up to the Signals group, I plan to ask the following three questions to Dominic regarding Observables’ interactions with Signals—

Intersection with ES Signals: In a world with both, what is the role of either?

  • This is an exciting proposal. Thank you for presenting it to TC39.
  • ES Signals are also an active proposal. Observables and Signals will seem superficially similar to many developers. Indeed, I’ve seen several comments on Signals conceptually depending on Observables as a primitive, although that seems to be impossible given Observables’ dependence on DOM. So I’d like clarification on what roles do you see Observables versus Signals serving, in a hypothetical future world with both. Do you see Observables and Signals as redundant or complementary? Do you see developers using both Observables and Signals?

Coordination/outreach to Signals champions?

  • I’d like to know whether there has been prior outreach and coordination with the champions of the ES Signals proposal, such as Daniel Ehrenberg and Rob Eisenberg. I think coordination between the two groups is very important here. It will probably be important to coordinate messaging to developers regarding the two proposals’ respective roles. Also, API uniformity between Observables and Signals where appropriate, especially in naming and maybe interoperability, also requires coordination between the two proposals. I haven’t seen evidence of direct coordination between the Signal and Observable groups except for Ben Lesh’s occasional appearance in Signals’ GitHub issues.

Interoperability with Signals: Observables feeding Signals or vice versa?

  • More on Signals. Have there been explorations on how an Observable could feed a Signal or vice versa? It would need to be WHATWG DOM, not core ECMAScript, that specifies such an API. The situation is somewhat analogous with WHATWG Streams and ECMAScript async iterators. I understand that Observables are probably closer to shipping than Signals are, so this could be deferred to a future DOM proposal, but this should still be explored early on.
19:08
<littledan>
well, I think those questions could lead to a little bit of confusion. We're always being asked to make signals based on observables, but it doesn't make sense because, at most, it's a way that we could take a callback as an argument. it does keep getting repeated. I'm worried about the opposite thing: what if people use observables when they want reactivity? (which observables are broken for, but signals works well for)
19:08
<littledan>
re: outreach: I was always aware of the Observables proposal and intermmitently in contact
19:09
<littledan>
for interoperability: some things in the DOM could be exposed as Observables which I think would be better handled as signals, e.g., ResizeObserver. But we can't say "don't use Observables" since we haven't proven out Signals yet
19:10
<nicolo-ribaudo>
Can you create a signal out of an observable?
19:10
<littledan>
you can!
19:10
<littledan>
it requires a 3-line snippet
19:10
<littledan>
the questions aren't bad but I'm not sure if they'll lead to productive conversation
19:11
<littledan>
but we're at risk of even worse, more unproductive conversation, if people get stuck on turf wars
19:16
<Ashley Claymore>
I think Observables can live next to Signals.
In Reactive Programming there are both Cells (states/signals) and also Events (Observables).
Events are the points when a state change is triggered.

It's possible to use Observables to implement Cells but it's not a good fit due to glitching.
19:24
<littledan>
I agree. I don't want it to turn into an observables-vs-signals fight
19:31
<jschoi>
Yes, I want to avoid turf wars.
I’m treating Observables’ coupling to DOM Events and thus WHATWG as a fait accompli.

So I hope that we can focus constructively on increasing Observables’ and Signals’ interoperability and coordination.

Suggestions on the questions are welcome. (For example, I can skip or delay the “what do you see their respective roles” question.)
20:42
<jschoi>
well, I think those questions could lead to a little bit of confusion. We're always being asked to make signals based on observables, but it doesn't make sense because, at most, it's a way that we could take a callback as an argument. it does keep getting repeated. I'm worried about the opposite thing: what if people use observables when they want reactivity? (which observables are broken for, but signals works well for)

Oh, Element finally properly synced and now I see all your responses.

I can hold off and avoid asking any of these three questions if you think that would be more productive, Daniel.

20:47
<jschoi>
(It’s good to hear that there’s been some communication/coordination between the two proposals’ drivers.)
20:50
<jschoi>
By interoperability I mostly mean this and vice versa. Being able to (ergonomically, easily) plug an observable into a signal or a signal into an observable.