Requesting a position on the Observable API

[domfarolino]

Hi there, at the Web Engines Hackfest I raised the question of how to get a WinterCG "position" about new web API proposals. Along with others, @littledan mentioned that for now, filing issues against this repository will do.

I'd like to get Winter's position on the Observable API, as proposed in https://github.com/WICG/observable. Observables are a long-awaited and highly desired ergonomic improvement for event handling.

I'll admit I'd still like to do my research on where exactly the line should be drawn between Observables and Signals in terms of their usage (at the moment I know almost nothing about Signals except for what some people described to me in person). But still it would be good to get a gut check on this proposal by experts over here, sooner than later. Thanks!

[mk-pmb]

Observables look really useful. However, the naming could be improved in some parts. Edit: I moved the details to #147 and #148.

[jasnell]

Observables are still a bit too new, I think, and haven't been broadly implemented natively in the various runtimes. We would need implementations in at least two non-browser runtimes to consider it.

Currently, I'm reserving my persona opinion on the API itself. I'd like to see it in the wild a bit more and see how folks make use of it in non-browser cases.

[ekwoka]

Currently, I'm reserving my persona opinion on the API itself. I'd like to see it in the wild a bit more and see how folks make use of it in non-browser cases.

The issue with this is once it is in the wild, opinion on the API don't really matter anymore.

[mk-pmb]

Edit: Nevermind, it seems that after a lot of confusion, there's an easy way out for everyone.

The Observable spec currently suffers from an upstream restriction that I consider hostile to readers of any affected code, so I'd like to point your all's attention to this request to allow meaningful names for AbortSignals.

[jasnell]

FYI, in order to better equip myself to evaluate whether we should take a position on the Observable API I've created two experimental implementations (one for workerd and one for Node.js, the former being a c++ based implementation and the latter being Javscript). Thus far I don't see any blocking concerns on a technical level, although it is clear there are still some WIP areas of the spec. What I am concerned about is whether there are sufficient non-browser use cases justifying the WinterCG taking a position on whether all WinterCG-aligned runtimes should implement it. I can see a number of hypothetical cases but I would very much like to see some input from folks who have solid, non-hypothetical cases where Observable will be useful to them.

[annevk]

@jasnell the proposal is for it to become part of EventTarget essentially as something you might use instead of addEventListener(). Presumably that is being used somewhat? It'd be quite valuable to know what Deno, Node.js, and others make of this.