-
Notifications
You must be signed in to change notification settings - Fork 13
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
Comments
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. |
The issue with this is once it is in the wild, opinion on the API don't really matter anymore. |
This comment was marked as resolved.
This comment was marked as resolved.
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 |
@jasnell the proposal is for it to become part of |
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!
The text was updated successfully, but these errors were encountered: