I agree in general with the view that React community is taking this whole reinventing the wheel every X months too far.
To me it seems like most of the new updates to React are not there to solve a problem most apps in the wild have, but rather to solve some very specific Facebook-related issue which 99.9% of us will actually never even encounter on our web apps because they will never be Facebook scale.
Every React update solves a very specific Facebook issue but it's because React is developed by Facebook for Facebook.
React was and is developed to solve Facebook problems, not community problems.
Unfortunately there is a lot of hype about corporate backed libraries and they get adopted by the community because the hype, not because they solve community's problems.
It does not mean these libraries are bad, quite contrary, the majority of them are very good engineered solutions, but at the end of the day, they solve corporate problems, not community problems.
After many years I’ve come to the simple conclusion that those who over engineer are not suited for this profession. It’s like accepting that hardcore Trump supporters are just too far gone.
I don’t understand why in web development there’s such a fanatical obsession with “managing state” as if you can’t just place objects somewhere and iterate through them or use browser eventing to tell parts of your app something happened to your data store.
It’s such a weird thing to me. You really need a library that?
From Angular.js to React, I’ve never seen the point other than that it was a sign that you were forced into using a framework’s lifecycle. I’d like to say React is still a library, but it calls your code, so that’s not quite right.
Flux was not handled with scrutiny by the react community. All the implementations of it were weird, so much so that people thought Redux was the least weird of all. Take that for what it’s worth. I consider it the dark ages of React.
The purpose is reactivity: when X state changes, Y needs to update. How do we know which Y's care about which Xes? How do we initialize and clean up those associations as Xes and Y's get created and destroyed? How do we make sure X can't be mutated without triggering Y to update and stay in sync?
This is necessary on the web because it doesn't operate in immediate-mode. React, despite its name, doesn't actually solve the reactivity problem (well, setState and hooks kind of do, but they're pretty basic). The big deal with "state management libraries" like Redux and MobX is that they give you an enshrined container of state that knows how to publish its changes to the things that care about it, in a way that's more performant and ergonomic than the naive approach. That comes with different caveats and constraints depending on the library you choose.
You mentioned events, which can be part of a solution (just like regular callbacks can), but they don't actually solve the hard part of the problem.
This hasn’t been a new concept for decades, though. What you’re describing is why we have event listeners. You dispatch events and only relevant listeners get those events.
You don’t need a library for it.
The “hard part” of the problem is that React doesn’t care about using simple solutions, because it has its own lifecycle you have to use. So inevitably any software that wants to interact with React would have to trigger React to respond to those events.
This architectural decision leads to engineering solutions that make state management seem like a complicated thing, but the “reactivity” issue you’re describing has nothing to do with state management.
It has everything to do with managing React to react to state changes. That’s not state management. That’s framework management.
You don't really have to do anything special with React's lifecycle in order to publish changes... you just call forceUpdate on a component to trigger itself and its children to re-render. The trick is avoiding rendering the parts of that tree which won't actually change. Redux solves this through immutability which allows for reference comparison ("if this component's props didn't change then the object will === the previous one, and we can skip it"). MobX does it by automatically wiring highly granular pub/sub relations between individual variables and the components that reference them.
Additionally, events aren't sufficient on their own because you need the state to actually be stored somewhere, for next time. Events don't hold state, they only pass a transient signal. And if you're manually both a) publishing an event and b) updating the corresponding state, you risk missing a case and having those two get out of sync (not to mention you'll be writing a whole lot of boilerplate logic). It'll also be really hard to change multiple pieces of state at once without having things temporarily disagree. I've worked on a project where this is basically what was done, and it was a nightmare of inconsistent intermediary states and race-conditions.
To put it differently: "state X changed" is a special case of "X happened" that needs quite a few special considerations in practice, and that's why state management abstractions are built atop the more general idea
I appreciate the granular details of what you're saying, but with every sentence, I just think to myself, yeah that's React's problem that it's offloading to others.
Maybe! But that would mean going all-in on the "React is a framework, not a library" thing. Right now they're straddling the line where they can still argue that they're maybe kind of just a library, even if most people don't really buy it at this point
I agree with all the overengineered stuff argument, but this is not as easy as you describe except for the simplest of the use cases.
For example, you might have on screen a component (something inside a modal for example) that might need some data (a newly created record maybe) which is some information that has been dispatched in the past, so either you have to foresee and pre registered every single listener on beforehand or you have to keep track of all the events or the data that was emitted with them. At that point you've invented a new state management solution.
What complex UI isn't obsessed with managing state? Android has definitely moved in a similar direction with RxJava, LiveData, and coroutines. I believe IOS has something similar. Is it possible you've only worked on backend-style projects before? UI programming has different hard parts.
I attribute react's problems to 2 things: not including state management in the lib, not deprecating old APIs for like concerns when updating major versions. I prefer Svelte or Vue.
If React had bundled state management, it would have been bad, it would have run hard afoul of your second concern, would never have been deprecateable, it would have been an anchor they could never cut loose. React would have been doomed.
People keep wanting React to be more (like this whole post) but I feel like smart in the know people all recognize what an incredible boon it is that React targeted a specific problem, that it engaged the community to find & work through solutions to other orthogonal concerns. React has been free to evolve, and these other orthogonal concerns have been free to evolve & shake out.
At this point, there's a couple pretty stable, well known, well respected answers to any orthogonal concern. Switching between them is not that bad, they all have a deliberate architecture & practice you can move towards that makes internal sense. React doesn't care.
People's desire to make React care & intertwine it's concerns is really confounding & weird to me. But it's easy to blog about, it's easy to spread some dissent. It's harder to write a good paean for what a correct, amazing, better than everyone-elses-attempt this was by the React team.
I loved what the team did with Flux. They talked about it, made it sound simple as heck, then told us to go implement it ourselves. We had all sorts of goes & attempts before React released their state management system. We had independent thought, we had many ideas, where-as if Facebook had just dropped Flux right away, shortly after release of React, we'd all just be a bunch of sheep & never have seen other ideas or explored the notion. Having a healthy group diversity around ideas, to support technical ecosystems is so bloody important, and this post & the desire to see concerns all bundled with one another to make it easy & thought-free, to get everyone following the same easy-path, they just sounds so wrong & short-sighted to me. They ignore to me the most powerful aspect of mankind: what amazing explorers we are, how great our vision & ability to see.
TL;DR Author is just riding on the hype with contrarian opinion. What sucks is that nowadays most sites won't load without JS. I notice because I use NoScript.
But! If you have done any desktop GUI development, you know that React is way closer to it than the old ways of composing web pages. If it is possible to render React, or anything that resembles desktop GUI frameworks, on server, then what exactly are you complaining about? Is the spaghetting with separate HTML, CSS, and JS glue really anything worth applauding?
Have worked on hook infested react components which lead to really unique bugs that are unique to react 16+. It's not that fun. The core premise of react is really useful, I mean the alternative in vanilla js is doing `var y = document.createElement('x'); y.appendChild(...)` and its very verbose and hard to follow. A react JSX component on the other hand can be taken in at a glance. But I still feel like the expression of change due to various triggers, or even over a period of time (as in animation) could be improved. How I don't know!
90% of the applications we use react for could be built in a more sustainable way with Unpoly or a similar solution. But that's not cool, so...here we are.
26 comments
[ 3.1 ms ] story [ 72.7 ms ] threadTo me it seems like most of the new updates to React are not there to solve a problem most apps in the wild have, but rather to solve some very specific Facebook-related issue which 99.9% of us will actually never even encounter on our web apps because they will never be Facebook scale.
Every React update solves a very specific Facebook issue but it's because React is developed by Facebook for Facebook.
React was and is developed to solve Facebook problems, not community problems.
Unfortunately there is a lot of hype about corporate backed libraries and they get adopted by the community because the hype, not because they solve community's problems.
It does not mean these libraries are bad, quite contrary, the majority of them are very good engineered solutions, but at the end of the day, they solve corporate problems, not community problems.
It’s such a weird thing to me. You really need a library that?
From Angular.js to React, I’ve never seen the point other than that it was a sign that you were forced into using a framework’s lifecycle. I’d like to say React is still a library, but it calls your code, so that’s not quite right.
That's exactly what a framework is.
If it was, you probably wouldn’t need all of this.
> A JavaScript library for building user interfaces
This is necessary on the web because it doesn't operate in immediate-mode. React, despite its name, doesn't actually solve the reactivity problem (well, setState and hooks kind of do, but they're pretty basic). The big deal with "state management libraries" like Redux and MobX is that they give you an enshrined container of state that knows how to publish its changes to the things that care about it, in a way that's more performant and ergonomic than the naive approach. That comes with different caveats and constraints depending on the library you choose.
You mentioned events, which can be part of a solution (just like regular callbacks can), but they don't actually solve the hard part of the problem.
You don’t need a library for it.
The “hard part” of the problem is that React doesn’t care about using simple solutions, because it has its own lifecycle you have to use. So inevitably any software that wants to interact with React would have to trigger React to respond to those events.
This architectural decision leads to engineering solutions that make state management seem like a complicated thing, but the “reactivity” issue you’re describing has nothing to do with state management.
It has everything to do with managing React to react to state changes. That’s not state management. That’s framework management.
Additionally, events aren't sufficient on their own because you need the state to actually be stored somewhere, for next time. Events don't hold state, they only pass a transient signal. And if you're manually both a) publishing an event and b) updating the corresponding state, you risk missing a case and having those two get out of sync (not to mention you'll be writing a whole lot of boilerplate logic). It'll also be really hard to change multiple pieces of state at once without having things temporarily disagree. I've worked on a project where this is basically what was done, and it was a nightmare of inconsistent intermediary states and race-conditions.
To put it differently: "state X changed" is a special case of "X happened" that needs quite a few special considerations in practice, and that's why state management abstractions are built atop the more general idea
For example, you might have on screen a component (something inside a modal for example) that might need some data (a newly created record maybe) which is some information that has been dispatched in the past, so either you have to foresee and pre registered every single listener on beforehand or you have to keep track of all the events or the data that was emitted with them. At that point you've invented a new state management solution.
People keep wanting React to be more (like this whole post) but I feel like smart in the know people all recognize what an incredible boon it is that React targeted a specific problem, that it engaged the community to find & work through solutions to other orthogonal concerns. React has been free to evolve, and these other orthogonal concerns have been free to evolve & shake out.
At this point, there's a couple pretty stable, well known, well respected answers to any orthogonal concern. Switching between them is not that bad, they all have a deliberate architecture & practice you can move towards that makes internal sense. React doesn't care.
People's desire to make React care & intertwine it's concerns is really confounding & weird to me. But it's easy to blog about, it's easy to spread some dissent. It's harder to write a good paean for what a correct, amazing, better than everyone-elses-attempt this was by the React team.
I loved what the team did with Flux. They talked about it, made it sound simple as heck, then told us to go implement it ourselves. We had all sorts of goes & attempts before React released their state management system. We had independent thought, we had many ideas, where-as if Facebook had just dropped Flux right away, shortly after release of React, we'd all just be a bunch of sheep & never have seen other ideas or explored the notion. Having a healthy group diversity around ideas, to support technical ecosystems is so bloody important, and this post & the desire to see concerns all bundled with one another to make it easy & thought-free, to get everyone following the same easy-path, they just sounds so wrong & short-sighted to me. They ignore to me the most powerful aspect of mankind: what amazing explorers we are, how great our vision & ability to see.
But! If you have done any desktop GUI development, you know that React is way closer to it than the old ways of composing web pages. If it is possible to render React, or anything that resembles desktop GUI frameworks, on server, then what exactly are you complaining about? Is the spaghetting with separate HTML, CSS, and JS glue really anything worth applauding?