Yeah I think I understate this. I do mention that by providing their own primitives they now have an opinion, and basically push some of the 3rd parties out. But you are saying it's more that by encouraging proprietary primitives it ensures lock in. All that being said I always felt React = FP thing was fictional, marketing hype thing. React = React simple as that.
I think your FP stuff is in the same category as XState where some people are actively searching ways to pull all state management out of React for this reason.
That being said I don't feel this is some sinister or even Facebook driven motive. Reactive libraries like Vue or Svelte have the same proprietary buy in on their primitives. Sure you can export the reactive system and use it elsewhere, but every detail in how it interacts with the templating and components is very much specific. These systems are just as invasive and promote lock in.
I think React was attempting to provide a composition model they could do smart things with. When you consider things like Suspense/Concurrent Mode and like these isomorphic stories. The only way we can do things smartly is to know what we are dealing with. When we are we done rendering etc.. Have the means to be able to orchestrate at a higher level that was part of their offering. You can do it other ways but they saw the need to ship with it for the next feature set. I think that was the motivation with the timing of this.
And that's the problem with the standards. Framework authors still feel like they are moving this stuff forward at such a pace standards aren't really catching up. Even if the client side render is becoming well understood, SSR and isomorphic is opening up completely new doors. Even Svelte in the client with their approach to animations is suggesting that standardization is a ways off.
So while I'm saying I think we will see this work to be agnostic. It will be the lowest common denominator of libraries. You will see the frameworks themselves accelerating in directions that aren't generically followed.
Personally I was on this train of standardization about 5 years ago. But as I worked more on my frameworks and realized the overhead cost, It is achievable but never quite as good. I wrote libraries to generalize reactive rendering (DOM Expressions is still bring your reactive system), swore by webcomponents, and thought that I'd land on TC-39 observable spec as basis for reactivity. In the past 5 years I realized everyone of those was a trap, or mostly useless beyond simple demos. It was something one can do but would never be the "best" way. Not today, never. Maybe new specs and new approaches changes that but fundamentally these do not align with the direction of things as they unfolded.
Of course there is enough of a desire for this that it will be a thing. And there will continue to be this tension. And it will be completely doable. However, there will be those (mostly from frameworks) that know their specialized solution is more optimal.
I mean sure you can always make an adaptor. And it looks like Svelte supports Observables right out of the box since their stores are subscribables. Most other reactive libraries can take a subscribable and have it write to one of their own primitives in a similar way.
So to clarify I don't see any problem if you prefer these different global state managed solutions. And I'd welcome people bringing other reactive libraries for global state management if it made sense as the interopt layer is fairly painless.
I was just saying that using Observables for the frameworks internals is less optimal than lighter weight subscription mechanisms. It can be done and I went down that path at one point, but it was bulky when it came to my templating goals. Mostly that spec Observables are cold, an unicast in nature, and we often want our reactivity hot, and multicast at the framework level. You almost always want Behavior Subjects using the RxJS term and mapping between them constantly is a bit tedious. I've seen some work to reduce this overhead though. RxJS-Autorun is a great little library geared at bridging that gap. I already played around with making a version of my renderer to use it, and it wasn't bad.
You can even use composable primitives to bring them into the library closer and replace local state management. But in those cases using the libraries own primitives is going to be the most performant. You remove any translation overhead. In most cases this is going to be minimal, so I wouldn't sweat it if it's your preferred experience. But like Svelte or React team is only going to be optimizing for their localized cases. Even Svelte stores adds a little bit of extra on top of Svelte's component reactivity. Again nothing worth worrying about, but there are tradeoffs. Mostly that the frameworks will continue to build more features that might demand more interaction points that will make these things potentially bulkier. It's really a decision of how much you value the cleanliness of your logic and how much you want to leverage framework unique traits. I'm not going to say anyway is right for all cases.
Yeah I see where you're coming from, you're always going to have to build some sort of layer on top of observables and whether that meshes with your design goals depends. Thanks for getting back to me!
In the past 5 years I realized everyone of those was a trap, or mostly useless beyond simple demos. It was something one can do but would never be the "best" way. Not today, never.
Generosity/portability/maintainability always comes with some overhead and performance loss. In traditional non-frontend development we always talk about breaking down into smaller, purer, more testable functions, using more interfaces that help doing better abstractoin, avoiding lock between business logic and particular frameworks. All these come with runtime overhead, or, at least, more compiling time for, say, rust.
It's always a tradeoff. ;(
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Yeah I think I understate this. I do mention that by providing their own primitives they now have an opinion, and basically push some of the 3rd parties out. But you are saying it's more that by encouraging proprietary primitives it ensures lock in. All that being said I always felt React = FP thing was fictional, marketing hype thing. React = React simple as that.
I think your FP stuff is in the same category as XState where some people are actively searching ways to pull all state management out of React for this reason.
That being said I don't feel this is some sinister or even Facebook driven motive. Reactive libraries like Vue or Svelte have the same proprietary buy in on their primitives. Sure you can export the reactive system and use it elsewhere, but every detail in how it interacts with the templating and components is very much specific. These systems are just as invasive and promote lock in.
I think React was attempting to provide a composition model they could do smart things with. When you consider things like Suspense/Concurrent Mode and like these isomorphic stories. The only way we can do things smartly is to know what we are dealing with. When we are we done rendering etc.. Have the means to be able to orchestrate at a higher level that was part of their offering. You can do it other ways but they saw the need to ship with it for the next feature set. I think that was the motivation with the timing of this.
And that's the problem with the standards. Framework authors still feel like they are moving this stuff forward at such a pace standards aren't really catching up. Even if the client side render is becoming well understood, SSR and isomorphic is opening up completely new doors. Even Svelte in the client with their approach to animations is suggesting that standardization is a ways off.
So while I'm saying I think we will see this work to be agnostic. It will be the lowest common denominator of libraries. You will see the frameworks themselves accelerating in directions that aren't generically followed.
Personally I was on this train of standardization about 5 years ago. But as I worked more on my frameworks and realized the overhead cost, It is achievable but never quite as good. I wrote libraries to generalize reactive rendering (DOM Expressions is still bring your reactive system), swore by webcomponents, and thought that I'd land on TC-39 observable spec as basis for reactivity. In the past 5 years I realized everyone of those was a trap, or mostly useless beyond simple demos. It was something one can do but would never be the "best" way. Not today, never. Maybe new specs and new approaches changes that but fundamentally these do not align with the direction of things as they unfolded.
Of course there is enough of a desire for this that it will be a thing. And there will continue to be this tension. And it will be completely doable. However, there will be those (mostly from frameworks) that know their specialized solution is more optimal.
Is Svelte not compatible with the Observable API? The library Effector is too. What precludes it from being the best way do you think?
I mean sure you can always make an adaptor. And it looks like Svelte supports Observables right out of the box since their stores are subscribables. Most other reactive libraries can take a subscribable and have it write to one of their own primitives in a similar way.
So to clarify I don't see any problem if you prefer these different global state managed solutions. And I'd welcome people bringing other reactive libraries for global state management if it made sense as the interopt layer is fairly painless.
I was just saying that using Observables for the frameworks internals is less optimal than lighter weight subscription mechanisms. It can be done and I went down that path at one point, but it was bulky when it came to my templating goals. Mostly that spec Observables are cold, an unicast in nature, and we often want our reactivity hot, and multicast at the framework level. You almost always want Behavior Subjects using the RxJS term and mapping between them constantly is a bit tedious. I've seen some work to reduce this overhead though. RxJS-Autorun is a great little library geared at bridging that gap. I already played around with making a version of my renderer to use it, and it wasn't bad.
You can even use composable primitives to bring them into the library closer and replace local state management. But in those cases using the libraries own primitives is going to be the most performant. You remove any translation overhead. In most cases this is going to be minimal, so I wouldn't sweat it if it's your preferred experience. But like Svelte or React team is only going to be optimizing for their localized cases. Even Svelte stores adds a little bit of extra on top of Svelte's component reactivity. Again nothing worth worrying about, but there are tradeoffs. Mostly that the frameworks will continue to build more features that might demand more interaction points that will make these things potentially bulkier. It's really a decision of how much you value the cleanliness of your logic and how much you want to leverage framework unique traits. I'm not going to say anyway is right for all cases.
Yeah I see where you're coming from, you're always going to have to build some sort of layer on top of observables and whether that meshes with your design goals depends. Thanks for getting back to me!
Generosity/portability/maintainability always comes with some overhead and performance loss. In traditional non-frontend development we always talk about breaking down into smaller, purer, more testable functions, using more interfaces that help doing better abstractoin, avoiding lock between business logic and particular frameworks. All these come with runtime overhead, or, at least, more compiling time for, say, rust.
It's always a tradeoff. ;(