3 ms·

> except that "reactivity" does not meet the bar of developers collectively having landed on a solution to a common problem Now that everyone seems to be in l

> except that "reactivity" does not meet the bar of developers collectively having landed on a solution to a common problem Now that everyone seems to be in love with signals, there is work going on in the web components community group to prepare a spec for a signal (or observable, not sure what they are trying to call it) primitive [0]. It seems that they are getting ready to bring it to TC39 as a proposal. (In the meantime, the Observable primitive from rxjs has been given a go-ahead for browser implementation. There is a proposal ready [1], and I think I heard that it may already be in Chrome behind a flag [2]). So yeah; it's gonna be fun. Especially if both groups call their primitive Observable :-) 0 - https://github.com/webcomponents-cg/community-protocols/issues/43 https://github.com/webcomponents-cg/community-protocols/issu... 1 - https://github.com/WICG/observable https://github.com/WICG/observable 2 - https://nitter.net/BenLesh/status/1737174784406933599 https://nitter.net/BenLesh/status/1737174784406933599

jauntywundrkind 3y ago
I'm pretty stressed out about the proliferation of standards here. It's indistinct to me why we need so many ways of hearing about a new thing; they seem the same general idea, but everyone has some insular notion, it feels like, and I don't get the value add, don't get why we'd have another. We already have a streams API that tells us of new things. Adding observables, adding signals, feels like a lot of totally different ideas that do mostly the same thing. What is missing from streams to make it cover these other cases? I suspect not a lot. But these are isolated cultures each possessed of their own idea, their own mentality, and there's not much binding glue forces to pull these disparate worlds together, even though it feels like the overlap is overwhelming. I feel like we are making a huge mistake letting these people chip more shit into the language, that we gain only more modes that don't work with each other. I love these communities, but not like this.
daotoad 3y ago
This proposal makes the same mistake as various stream implementations (including RxJS in the past) of making operators methods on the observable. This means you can't add custom operators without subclassing or doing weird crap with proxies. When RxJS stopped using instance methods to implement operators, it opened up the ability to create custom, domain appropriate operators which I found key to writing comprehensible and maintainable code. We really need a `pipe` operator, at minimum. https://rxjs.dev/guide/operators#creating-custom-operators https://rxjs.dev/guide/operators#creating-custom-operators
- azangru 3y ago
  > This proposal makes the same mistake as various stream implementations (including RxJS in the past) of making operators methods on the observable. I don't think they are making a mistake. I am sure Ben knows what he is doing, given how it was he who refactored rxjs 5 with all operators being methods on the Observable, to rxjs 6 with pipeable operators. But, their objective is not to bring rxjs into the browser, but rather to bring the Observable primitive into the browser. And, like Array prototype, which has methods, Observable, in order to be even minimally useful, needs some methods, which they modelled after TC39 iterators, for the sake of consistency. They say: > We expect userland libraries to provide more niche operators that integrate with the Observable API central to this proposal, potentially shipping natively if they get enough momentum to graduate to the platform. But for this initial proposal, we'd like to restrict the set of operators to those that follow the precedent stated above, similar to how web platform APIs that are declared Setlike and Maplike have native properties inspired by TC39's Map and Set objects. Therefore we'd consider most discussion of expanding this set as out-of-scope for the initial proposal, suitable for discussion in an appendix. Any long tail of operators could conceivably follow along if there is support for the native Observable API presented in this explainer. As to > We really need a `pipe` operator, at minimum Maybe we don't. Note that in RxJS version 8, they have introduced a new way of piping observables, which is the rx function [0]. Maybe they are thinking of something similar for the browser. Or maybe they are thinking of using the native pipeline operator if it ever gets approved. In the meantime, for any complex manipulations on observables, users will probably still import relevant functions from libraries. 0 - https://github.com/ReactiveX/rxjs/issues/7203 https://github.com/ReactiveX/rxjs/issues/7203
Vinnl 3y ago
Wow, I'm actually a pretty big fan of the original Observable, so on the one hand I'm pretty happy about that (assuming it will get standardised, rather than being a Chrome-only API). But on the other hand, indeed, like signals, I don't really think it meets that bar - especially since Observables have been widely available and actively worked on for a long time, without seeing wide adoption.
- azangru 3y ago
  > especially since Observables have been widely available and actively worked on for a long time, without seeing wide adoption Take a look at the "Userland libraries" section [0] of the proposal (almost certainly written by Ben). He argues that observables get reinvented in the userland in various libraries over and over again. It is a primitive, like Promise, only better, and with very sound theoretical underpinnings. [0] - https://github.com/WICG/observable?tab=readme-ov-file#userland-libraries https://github.com/WICG/observable?tab=readme-ov-file#userla...
  - troupo 3y ago
    I think people have been burned by RxJS where observables are "cold" by default and the source of many problems, over subscriptions, false starts etc. The modern swing back to signals (which in a way stem from Knockout's observables) seems to be simpler and easier to reason about.
megaman821 3y ago
There are proposals for both Observables and Signals.
bnchrch 3y ago
As someone who's first job out of college included a large knockout.js codebase (two way observables). All I can say is any developer reaching for Signals today beware. This pattern is great is very small apps, but if you grow any larger the debugging story becomes a complete mess as it can be come nearly impossible to know which component modified the state of the observable and when. Also this may be my first Old Timey Developer opinion Ive written where I warn developers about reinventing our mistakes of the past.

jauntywundrkind 3y ago

I'm pretty stressed out about the proliferation of standards here. It's indistinct to me why we need so many ways of hearing about a new thing; they seem the same general idea, but everyone has some insular notion, it feels like, and I don't get the value add, don't get why we'd have another. We already have a streams API that tells us of new things. Adding observables, adding signals, feels like a lot of totally different ideas that do mostly the same thing. What is missing from streams to make it cover these other cases? I suspect not a lot. But these are isolated cultures each possessed of their own idea, their own mentality, and there's not much binding glue forces to pull these disparate worlds together, even though it feels like the overlap is overwhelming. I feel like we are making a huge mistake letting these people chip more shit into the language, that we gain only more modes that don't work with each other. I love these communities, but not like this.

daotoad 3y ago

This proposal makes the same mistake as various stream implementations (including RxJS in the past) of making operators methods on the observable. This means you can't add custom operators without subclassing or doing weird crap with proxies. When RxJS stopped using instance methods to implement operators, it opened up the ability to create custom, domain appropriate operators which I found key to writing comprehensible and maintainable code. We really need a `pipe` operator, at minimum. https://rxjs.dev/guide/operators#creating-custom-operators https://rxjs.dev/guide/operators#creating-custom-operators

azangru 3y ago
> This proposal makes the same mistake as various stream implementations (including RxJS in the past) of making operators methods on the observable. I don't think they are making a mistake. I am sure Ben knows what he is doing, given how it was he who refactored rxjs 5 with all operators being methods on the Observable, to rxjs 6 with pipeable operators. But, their objective is not to bring rxjs into the browser, but rather to bring the Observable primitive into the browser. And, like Array prototype, which has methods, Observable, in order to be even minimally useful, needs some methods, which they modelled after TC39 iterators, for the sake of consistency. They say: > We expect userland libraries to provide more niche operators that integrate with the Observable API central to this proposal, potentially shipping natively if they get enough momentum to graduate to the platform. But for this initial proposal, we'd like to restrict the set of operators to those that follow the precedent stated above, similar to how web platform APIs that are declared Setlike and Maplike have native properties inspired by TC39's Map and Set objects. Therefore we'd consider most discussion of expanding this set as out-of-scope for the initial proposal, suitable for discussion in an appendix. Any long tail of operators could conceivably follow along if there is support for the native Observable API presented in this explainer. As to > We really need a `pipe` operator, at minimum Maybe we don't. Note that in RxJS version 8, they have introduced a new way of piping observables, which is the rx function [0]. Maybe they are thinking of something similar for the browser. Or maybe they are thinking of using the native pipeline operator if it ever gets approved. In the meantime, for any complex manipulations on observables, users will probably still import relevant functions from libraries. 0 - https://github.com/ReactiveX/rxjs/issues/7203 https://github.com/ReactiveX/rxjs/issues/7203

Vinnl 3y ago

Wow, I'm actually a pretty big fan of the original Observable, so on the one hand I'm pretty happy about that (assuming it will get standardised, rather than being a Chrome-only API). But on the other hand, indeed, like signals, I don't really think it meets that bar - especially since Observables have been widely available and actively worked on for a long time, without seeing wide adoption.

azangru 3y ago
> especially since Observables have been widely available and actively worked on for a long time, without seeing wide adoption Take a look at the "Userland libraries" section [0] of the proposal (almost certainly written by Ben). He argues that observables get reinvented in the userland in various libraries over and over again. It is a primitive, like Promise, only better, and with very sound theoretical underpinnings. [0] - https://github.com/WICG/observable?tab=readme-ov-file#userland-libraries https://github.com/WICG/observable?tab=readme-ov-file#userla...
- troupo 3y ago
  I think people have been burned by RxJS where observables are "cold" by default and the source of many problems, over subscriptions, false starts etc. The modern swing back to signals (which in a way stem from Knockout's observables) seems to be simpler and easier to reason about.

megaman821 3y ago

There are proposals for both Observables and Signals.

bnchrch 3y ago

As someone who's first job out of college included a large knockout.js codebase (two way observables). All I can say is any developer reaching for Signals today beware. This pattern is great is very small apps, but if you grow any larger the debugging story becomes a complete mess as it can be come nearly impossible to know which component modified the state of the observable and when. Also this may be my first Old Timey Developer opinion Ive written where I warn developers about reinventing our mistakes of the past.