4 ms·

On funding and work and someone willing to spend the time to write and do the research - not because of inherent opposition.

by inglor 4y ago

WorldMaker 4y ago
My impression was that it stalled out mostly because to make good use of Observables you need a pipeline library like RxJS or xstream anyway, it's not the job of TC-39 to pick a "winner library", and if you are always using libraries anyway it's "easy enough" to just align the libraries themselves for interop with each other through duck typing, which they all sort of did on their own. The syntax that these libraries could benefit the most from is in the separate Pipe Operator proposal, which has been progressing through the stages and doesn't seem to be stalled, and there's intentionally no direct dependency on Observables (as the Pipe Operator also works great for Iterables libraries). It may still be useful to get the Observables proposal further along for the same reasons it is great to have Promises standardized including in terms of encouraging usage in more native APIs. It is kind of silly that none of the SomethingObserver browser/DOM APIs (ResizeObserver, IntersectionObserver, et al) naturally return things that are duck-typably Observables despite "Observer" in their name and always need Observable wrappers.
- azangru 4y ago
  > My impression was that it stalled out mostly because to make good use of Observables you need a pipeline library like RxJS or xstream anyway, As Ben Lesh explains, Observable is a primitive that is very powerful on its own. It can produce multiple values (in which it is similar to async iterables and different from promises); it has a mechanism for cancellation (as opposed to promises, and probably even async iterables); it probably can be both synchronous (if the data it produces finishes synchronously) and asynchronous; it is lazy, which makes it more composable than promises. Multiple values and cancellation are the big things I can remember. Pipeline libraries (aka "operators") are downstream from that, and can be built in the userland.
  - WorldMaker 4y ago
    It just sounds like you agree with my full comment if you read the whole thing? I do know what Observables are. I personally do think they are a useful primitive even without the downstream pipeline libraries (though a good pipeline library is indispensable for getting good work done). My impression has been that TC-39 has had a harder time being convinced they are a primitive that should be codified at the language level, because they are today mostly wrapped in large user space libraries just fine and don't need direct syntax (such as the relationships between Iterables and Generators and Iterables and for/of; or the relationship between Promises and async/await). Even the DOM disconnect here where I personally would love to see the Primitive more actively used is not entirely TC-39's fault because DOM APIs are on "the other side of the fence" from TC-39 in the WHATWG and W3C working groups. I'd love to see the Observable proposal move further along. I realize it hasn't because my impression is that it isn't a priority from TC-39's perspective. Again, I personally disagree with that impression. It's just the impression I'm getting when I read through issues and comments on the proposal.
azangru 4y ago
Funding is the key, yes. As far as I understand from Ben Lesh [0], a TC39 proposal needs a champion, and a champion can only be a TC39 member, and to become a TC39 member you need a company financially sponsoring your place. So previously, when Netflix was sponsoring Jafar Husain, he was able to prepare and update the Observable proposal; but after he left Netflix, the Observable proposal has lost its champion. Ben isn't on TC39 (he wasn't there even when he was at Google, let alone now), so he can't move the needle forward. He mentioned one person — who I think was involved in the proposal for the pipeline operator — as being sort of interested; but not to the point of becoming a champion. Without a champion — which means without a strong interest by big companies — this proposal is fated to remain stalled. I believe I heard Ben say that he doesn't have high hopes for it anymore. [0] - If I remember correctly, he explains it here: https://youtu.be/IX86lE-skeQ?t=2107 https://youtu.be/IX86lE-skeQ?t=2107
- inglor 4y ago
  The blocker isn't TC39 membership or being a champion though. It's blocked on someone actually working on it, writing the docs and editing the spec text, answering the questions brought up etc. If you can find someone willing to do that, I'm happy to help you find a TC39 delegate to help you with the committee stuff (Either with my Node.js hat with our delegate or with my Microsoft one). I'll also guarantee Ben (who is a friend) would be happy to help he just doesn't have the time to work on the proposal itself.

On funding and work and someone willing to spend the time to write and do the research - not because of inherent opposition.

by inglor 4y ago

On funding and work and someone willing to spend the time to write and do the research - not because of inherent opposition.

WorldMaker 4y ago

My impression was that it stalled out mostly because to make good use of Observables you need a pipeline library like RxJS or xstream anyway, it's not the job of TC-39 to pick a "winner library", and if you are always using libraries anyway it's "easy enough" to just align the libraries themselves for interop with each other through duck typing, which they all sort of did on their own. The syntax that these libraries could benefit the most from is in the separate Pipe Operator proposal, which has been progressing through the stages and doesn't seem to be stalled, and there's intentionally no direct dependency on Observables (as the Pipe Operator also works great for Iterables libraries). It may still be useful to get the Observables proposal further along for the same reasons it is great to have Promises standardized including in terms of encouraging usage in more native APIs. It is kind of silly that none of the SomethingObserver browser/DOM APIs (ResizeObserver, IntersectionObserver, et al) naturally return things that are duck-typably Observables despite "Observer" in their name and always need Observable wrappers.

azangru 4y ago
> My impression was that it stalled out mostly because to make good use of Observables you need a pipeline library like RxJS or xstream anyway, As Ben Lesh explains, Observable is a primitive that is very powerful on its own. It can produce multiple values (in which it is similar to async iterables and different from promises); it has a mechanism for cancellation (as opposed to promises, and probably even async iterables); it probably can be both synchronous (if the data it produces finishes synchronously) and asynchronous; it is lazy, which makes it more composable than promises. Multiple values and cancellation are the big things I can remember. Pipeline libraries (aka "operators") are downstream from that, and can be built in the userland.
- WorldMaker 4y ago
  It just sounds like you agree with my full comment if you read the whole thing? I do know what Observables are. I personally do think they are a useful primitive even without the downstream pipeline libraries (though a good pipeline library is indispensable for getting good work done). My impression has been that TC-39 has had a harder time being convinced they are a primitive that should be codified at the language level, because they are today mostly wrapped in large user space libraries just fine and don't need direct syntax (such as the relationships between Iterables and Generators and Iterables and for/of; or the relationship between Promises and async/await). Even the DOM disconnect here where I personally would love to see the Primitive more actively used is not entirely TC-39's fault because DOM APIs are on "the other side of the fence" from TC-39 in the WHATWG and W3C working groups. I'd love to see the Observable proposal move further along. I realize it hasn't because my impression is that it isn't a priority from TC-39's perspective. Again, I personally disagree with that impression. It's just the impression I'm getting when I read through issues and comments on the proposal.

azangru 4y ago

Funding is the key, yes. As far as I understand from Ben Lesh [0], a TC39 proposal needs a champion, and a champion can only be a TC39 member, and to become a TC39 member you need a company financially sponsoring your place. So previously, when Netflix was sponsoring Jafar Husain, he was able to prepare and update the Observable proposal; but after he left Netflix, the Observable proposal has lost its champion. Ben isn't on TC39 (he wasn't there even when he was at Google, let alone now), so he can't move the needle forward. He mentioned one person — who I think was involved in the proposal for the pipeline operator — as being sort of interested; but not to the point of becoming a champion. Without a champion — which means without a strong interest by big companies — this proposal is fated to remain stalled. I believe I heard Ben say that he doesn't have high hopes for it anymore. [0] - If I remember correctly, he explains it here: https://youtu.be/IX86lE-skeQ?t=2107 https://youtu.be/IX86lE-skeQ?t=2107

inglor 4y ago
The blocker isn't TC39 membership or being a champion though. It's blocked on someone actually working on it, writing the docs and editing the spec text, answering the questions brought up etc. If you can find someone willing to do that, I'm happy to help you find a TC39 delegate to help you with the committee stuff (Either with my Node.js hat with our delegate or with my Microsoft one). I'll also guarantee Ben (who is a friend) would be happy to help he just doesn't have the time to work on the proposal itself.