Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Requesting a position on the Observable API #72

Open
domfarolino opened this issue Jun 6, 2024 · 6 comments
Open

Requesting a position on the Observable API #72

domfarolino opened this issue Jun 6, 2024 · 6 comments

Comments

@domfarolino
Copy link

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
Copy link

mk-pmb commented Jun 6, 2024

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

@jasnell
Copy link
Contributor

jasnell commented Jun 7, 2024

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
Copy link

ekwoka commented Jun 10, 2024

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

This comment was marked as resolved.

@jasnell
Copy link
Contributor

jasnell commented Jun 10, 2024

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
Copy link

annevk commented Jun 17, 2024

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants