2025-04-01 [05:11:23.0432] Huh, I don't seem to have permission to invite people here. Could someone add @jkup:matrix.org ? [05:11:47.0999] and Linus Groh [05:42:26.0153] littledan done and done [05:43:05.0111] hi & thanks! [05:43:36.0038] 👋 [08:00:46.0739] Community call starting now! https://us02web.zoom.us/j/84763180621?pwd=bjVBT1B4dzdhdk80V3lQZG41eEVCZz09 2025-04-16 [11:47:48.0566] 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. 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. [11:48:57.0920] * 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. [12:08:20.0842] 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) [12:08:42.0101] re: outreach: I was always aware of the Observables proposal and intermmitently in contact [12:09:25.0729] 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 [12:10:07.0411] Can you create a signal out of an observable? [12:10:25.0687] you can! [12:10:30.0412] it requires a 3-line snippet [12:10:42.0418] the questions aren't *bad* but I'm not sure if they'll lead to productive conversation [12:11:00.0562] but we're at risk of even worse, more unproductive conversation, if people get stuck on turf wars [12:16:48.0593] 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. [12:24:57.0368] I agree. I don't want it to turn into an observables-vs-signals fight [12:31:54.0925] 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 interoperability and coordination. Suggestions on the questions are welcome. [12:36:23.0706] * 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 their 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.) [12:37:17.0653] * 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.) [13:42:11.0516] > <@littledan:matrix.org> 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. [13:47:29.0295] It’s good to hear that there’s been some communication between the two proposals’ drivers. [13:47:40.0929] * (It’s good to hear that there’s been some communication between the two proposals’ drivers.) [13:48:01.0331] * (It’s good to hear that there’s been some communication/coordination between the two proposals’ drivers.) [13:50:28.0232] > <@nicolo-ribaudo:matrix.org> Can you create a signal out of an observable? By interoperability I mostly mean this and vice versa. Being able to plug an observable into a signal or a signal into an observable. [13:50:47.0828] > <@nicolo-ribaudo:matrix.org> Can you create a signal out of an observable? * 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. 2025-04-17 [04:54:07.0769] this is a good goal. It'd be good if you ask questions pushing towards this. [04:54:31.0768] what I don't want is for people to say, "OK that means signals have to be DOM" since that would make no sense [06:36:18.0519] jschoi: I encourage you to ask these sorts of questions [06:36:38.0950] just keeping in mind avoiding those particular sorts of confusion [08:38:23.0720] Really appreciate both of your comments and questions on this presentation! [09:17:37.0685] When littledan said he saw multiple ways to layer better with Observable and AbortController, e.g., integrating EventTarget as HTML integration on top of ES stuff, and the possibility of a new API that’s user-friendlier than AbortController, I got pretty excited. [09:28:25.0029] Yeah it'd be great to work together on that! I think an upgraded AbortController would be an essential thing if we want interop between frameworks -- this is kind of orthogonal to signals, but everyone has a global which is the current disposal context, and nests these [09:28:48.0680] this is my very rough gist about the topic, which I need to improve https://gist.github.com/littledan/47b4fe9cf9196abdcd53abee940e92df