5 ms·

While I agree with the general gist of the article (and please, yes, it seems like a minor thing, but give us resizable iframes), except that "reactivity" does

by Vinnl 3y ago

While I agree with the general gist of the article (and please, yes, it seems like a minor thing, but give us resizable iframes), except that "reactivity" does not meet the bar of developers collectively having landed on a solution to a common problem. There are a couple of frameworks with similar, but different, approaches to it, and yet none of them is truly widespread. I'm very sceptical that standardisation would hit the right mark at this point in time. But yes, that is basically what we saw with Web Components. People took drew the wrong conclusions about what problems React solved ("everything is a component"), and then tried to retrofit Web Components as a native solution to the problem - with the added assumption that just because it was built-in, it was better.

aatd86 3y ago
Agreed. It's true that reactivity is needed but I also don't think it's time to standardize yet. There has already been attempts in the past too such as mutation observers. Too early.
azangru 3y ago
> 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
vanderZwan 3y ago
> except that "reactivity" does not meet the bar of developers collectively having landed on a solution to a common problem I think the request for a native API for a Morph DOM/Virtual DOM has a similar problem. He wants a native solution so the frameworks can "focus on differentiating based on the convenience of their APIs", but he's forgetting that any native API will in itself impose a style on the frameworks if the latter want to be performant. Given the diversity among current solutions, that would be the same as picking one of them to thrive and all the others to be forced to become more like it. Which is the opposite of what he wants. Also, it's not like you can take any JS-based solution, make it native, and expect it to be faster because now it's made with magic C++ pixie dust. Also, maybe the different internal data structures among browsers means that they each would prefer different reconciliation approaches, making it hard for them to agree on anything. I'm not saying that it's impossible to have a well-designed native solution that makes everything nicer, but it's also not exactly a trivial problem to solve. And unlike JavaScript frameworks, once it's standardized the browser vendors are stuck with it, so I can understand if they are conservative about it.
- Vinnl 3y ago
  I think one thing to keep in mind is that just because something is available in the browser, that doesn't mean that all other approaches are suddenly moot and will never be able to displace it - XMLHTTPRequest is also still available, for example, but did get replaced by `fetch`. But in general, you raise a good point - just because something worked well with developer tooling, doesn't mean that it would work well when integrated in the browser. You see the same e.g. when people are calling for runtime type validation in the browser just because they like TypeScript, even though the pros and cons would be completely different.
  - vanderZwan 3y ago
    > XMLHTTPRequest is also still available, for example, but did get replaced by `fetch`. True, although that also highlights my "once it's standardized the vendors are stuck with it forever" point
  - 8n4vidtmkvmk 3y ago

by Vinnl 3y ago

aatd86 3y ago

Agreed. It's true that reactivity is needed but I also don't think it's time to standardize yet. There has already been attempts in the past too such as mutation observers. Too early.

azangru 3y ago

> 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

vanderZwan 3y ago

> except that "reactivity" does not meet the bar of developers collectively having landed on a solution to a common problem I think the request for a native API for a Morph DOM/Virtual DOM has a similar problem. He wants a native solution so the frameworks can "focus on differentiating based on the convenience of their APIs", but he's forgetting that any native API will in itself impose a style on the frameworks if the latter want to be performant. Given the diversity among current solutions, that would be the same as picking one of them to thrive and all the others to be forced to become more like it. Which is the opposite of what he wants. Also, it's not like you can take any JS-based solution, make it native, and expect it to be faster because now it's made with magic C++ pixie dust. Also, maybe the different internal data structures among browsers means that they each would prefer different reconciliation approaches, making it hard for them to agree on anything. I'm not saying that it's impossible to have a well-designed native solution that makes everything nicer, but it's also not exactly a trivial problem to solve. And unlike JavaScript frameworks, once it's standardized the browser vendors are stuck with it, so I can understand if they are conservative about it.

Vinnl 3y ago
I think one thing to keep in mind is that just because something is available in the browser, that doesn't mean that all other approaches are suddenly moot and will never be able to displace it - XMLHTTPRequest is also still available, for example, but did get replaced by `fetch`. But in general, you raise a good point - just because something worked well with developer tooling, doesn't mean that it would work well when integrated in the browser. You see the same e.g. when people are calling for runtime type validation in the browser just because they like TypeScript, even though the pros and cons would be completely different.
- vanderZwan 3y ago
  > XMLHTTPRequest is also still available, for example, but did get replaced by `fetch`. True, although that also highlights my "once it's standardized the vendors are stuck with it forever" point
- 8n4vidtmkvmk 3y ago