Comment by strogonoff
7 hours ago
The reason for React’s “draw the rest of the owl” (which is a great way to describe it) mindset is that it’s born not as a framework but as a library, and to this day self-identifies as such. It by design tells you nothing about and is agnostic with respect to how you organise your code, where to put tests, what bundler to use, etc.
IIRC React itself doesn’t even know anything about the Web or DOM, as that integration is supplied by the pluggable reconciler, which lives in a separate library (ReactDOM).
One could argue that with the amount of batteries included perhaps it ought to undergo a grand status change, but until then it’s hard to blame on the authors of a library that they are not delivering a framework.
Indeed but while being a library is okay for math tools or pdf generation, it evidently didn't work well for building UI components.
Did it not work? Many successful and complex sites and apps use React—whether directly or via a framework (Next, Astro, or something homegrown)—and indeed many frameworks are built on React.
> math tools or pdf generation
In this case the original scope of the library was “reactive rendering”, which sort of makes sense.
It worked as in react is the de facto frontend choice.
It didn't work as in if I were to ask for the router, state management, etc library, there would be a combinatorial explosion of react "frameworks", all sucking in different ways.
I am (and supposedly grandparent also) on the option that react leaves out way too much that would still be well in the scope of a 'UI framework', and while modularity can be a good thing in certain things, more modular, more moving parts does increase complexity.
I've been there since the early days of React and I haven't seen a single React codebase which isn't a pile of duck-taped random packages, often leading to poor user performance.
Maybe it can be done, maybe not, but the average front-end dev doesn't have the insights to fill the gaps that React has left.
1 reply →