React Ruined Web Development
medium.com
medium.com
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.
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?