3 ms·

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 o

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

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