-
Notifications
You must be signed in to change notification settings - Fork 90
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
Is there any update? #214
Comments
up |
It seems this proposal do not have active champions, and never have updates in TC39 meetings in last 5 years. |
The language can be considered to be standard if it contains these type of essential classes which are very useful🙂 |
This actually has updates, it's moved to standardize by Google and Ben at https://github.com/domfarolino/observable seeking standardization as part of the web platform and not the language. |
I continue to encourage them to bring it to TC39; imo that's where it belongs. |
Am just wondering why it cant be language primitive rather than being web platform specific. Since this is highly related to language specific (i guess). Literally i see that asynchronous classes are the future (now, it was playing major role at library-level only). So in my opinion, it needs to be language primitive |
@codesculpture those two are not exclusive, also WICG/observable#30 (comment) |
If it already exists in the web, it won’t likely reach consensus for being in the language - promises only landed in one spec for that reason. |
We are having event emitters in node.js, we can build something better than that using observables, i cant say any existing stuffs which we can replace by observable in node for now. But it totally will be helpful i would say |
Can u elaborate this, please? |
What I mean is, if the web has a thing, there's not going to be much appetite to add it to the language. |
Can we expect this to happen or is there anything other we can do it to happen |
For what it's worth promises landed in a WHATWG spec first and then moved to JavaScrip via TC39 (promises are kind of complicate since both specs were based on a third userland spec). So if anything this makes an argument to add it to both since both the language and the platform have APIs that need this sort of thing. Both can also consume it from each other. It's been ±10 years so recollection is kind of vague. |
Also:
Sure there is a lot of stuff to do observables have been blocked mostly on actual work done. You should reach out to @benlesh with a clear email of what you know and how much time you commit to spend on this. |
Seems scary, isnt there any possible way that this can be happen quickly than a decade. I know my question is dumb. But whatever |
@codesculpture observables and most stuff have always been blocked on someone either funding people to work on it or doing the work themselves. If you're willing to do either it can progress pretty quickly. Otherwise we can mostly wait. |
I mean i was really interested in bringing this in, but am an amateur (under grad and still studying). But i can put my all time to do this at whatever cost. If u think i can help, can u just navigate me how i can start please? |
Sure, nothing in the spec is rocket science - you would email @benlesh with the following email:
Contents:
And I'm sure he can guide you from there. If he doesn't answer let me know and I'll ping him but he's generally a nice guy. |
Can i get his email? |
Sure, let me ask him. You can also email me at [email protected] and I'll forward it to him |
Hey i sent u the email and happy to see people like you who are trying to help others. Very thanks @benjamingr |
FWIW: I'm not an owner of this repository. So I'm not sure what I could provide someone who wanted to work in the TC39 space. My understanding is that this proposal would effectively require sponsorship from a member company, ergo $$$ and time (which is also $$$). |
@benlesh it needs a champion, for which Google employees are eligible like @domfarolino. |
Given the precedent of |
@domfarolino there's no doubt it'd be useful in the DOM, but completing the fourth quadrant of GTOR seems foundational enough and much broader than the web. |
@benlesh i agree! the best way to get both, tho, is to land it in the language first :-) |
I'm a little confused what "getting both" means. You can only have Observables in one spec, right? If it's in WHATWG DOM, there's nothing stopping TC39 standardization if the right TC39 groundwork was eventually laid (I'm imagining some event emitting infrastructure and token-based cancellation primitives introduced at that layer). But all that groundwork has already been laid in the web platform, and TC39 seems to not have an issue with that, right? |
The reverse is true - once it’s in WHATWG, the chances of it landing in tc39 approach zero. |
Hey guys, i see that whatwg has specific repo for streams (Readable Streams, Writable Stream, Transform Stream) Is that possible that we can propose this "Observable" there. Sorry if my question is dumb. But just want to know if that whatwg's stream repo help this proposal to ship fast. |
@codesculpture Observables is currently being proposed in https://github.com/domfarolino/observable and will be moved to https://github.com/WICG soon. The goal is to standardize it in the DOM Standard ultimately, so I don't think there's a need to integrate with the Streams Standard. |
@domfarolino So, do u have any future plan to move this (https://github.com/domfarolino/observable) proposal to tc39 from whatwg (maybe after this accepted) |
@codesculpture if it depends on AbortSignal (which, ftr, I haven't been convinced is necessary) then it couldn't move to tc39 until AbortSignal exists in the language, which it's unlikely to ever do (due to it being shipped in browsers without going through tc39 first) |
No. We are planning to standardize it in the WHATWG as I said earlier, after moving to WICG as an intermediate step. I'm not going to rule out TC39 ever adopting Observables in the future, if they had the same semantics as in the web platform and wanted to move it there, but that'd likely benefit from some kind of cancelation primitive and event target interface, which ECMAScript doesn't have. |
No description provided.
The text was updated successfully, but these errors were encountered: