How did we get here - a short history of frameworks

I've built SPA applications with JavaScript before front-end frameworks (angular.js) came about.

Those days SPAs were jQuery-heavy piles of software engineering "inventions" glued together by scripts and closure-based namespaces - the early ancestors or modern modules.

Since everything was custom-made by "the senior dev", there was no documentation and little of the original idea was transmitted to juniors without a serious disturbance.

Angular.js

That was the context in which Angular.js came about.
It offered a good documentation, interesting concepts and clear-cut separation of responsibility between them (except the difference between the service and provider which was arguably the most famous angular interview question).

But Angular.js was built yet in the now-legacy "pages-mindset" following initial ideas around HTML and CSS.
While it was fine for some time, as Web 2.0 started to kick-off with rich experiences where focus shifted even more (from information sharing) towards user indulgence - UX became mission-critical.

React.js

And React was the one that offered a new way of keeping websites more consistent by shifting the paradigm from pages mindset to component composition.

Now websites were not only built composed from self-contained, reusable blocks like the Lego (CSS needed a while to catch up) but it was also less opinionated than Angular.js when it comes to the front-end architecture and especially state management.
"React is the 'V(iew)' in the MVC" - was the main catch phrase those days.

MVC roots of the front-end frameworks and React as "the V"

We must remember that those were times when rich front-ends were primarily built by re-specialized PHP developers coming from Symphony / Cake PHP Frameworks background - therefore MVC was a natural structural design pattern for them (and that for long influenced the front-end frameworks).

But since React was "the V", then what about the Model and Controller? What about the logic and communication?

Here we come to the central problem since the dawn of React.

The problem - React's attempts to "do more"

The first approach React took towards the State Management sounded awesome (and trivial) - let's just pass the whole state from the root component to its individual leaves via props - propagating it through all components in-the-middle like a waterfall.
And boy... it worked so beautifully. At least for the simple examples in documentation.

But since real front-end application were much larger, as a developer those days you could witness 10-30 different props shared from the App through the whole React tree just to hit their leaf components.
Official solution? Just share them via ...props syntax.

But typing ...props reduced visibility (of which props actually are passed down) leading to many errors and overall... it was just a hack.

Flux Architecture and Redux

So Flux architecture with the concept of Stores, Dispatchers, and Actions came about (from React team), and then Redux (a simplified version of Flux - for juniors by a junior).

Flux was better than Redux but a great documentation (including first-and-foremost a complete, free video tutorial on egghead.io), simplicity of having a single Store, and some "toys for boys" (Redux DevTools with "time-travelling") won developers over and started Dan Abramov's (inexperienced, yet very charismatic 19-years-old freelancer) career in Facebook's React core team.

So, with everyone having their hands on Redux, Flux architecture being completely forgotten (or even never discovered) all we needed to do to have a complete, easy, flexible, and universal solution for front-end development was to incrementally move out from Redux back to Flux with some default bootstrap that would enable junior devs start small quickly and a guide on best practices how to scale.

Mobx - final solution?

All we needed was something like... Mobx - way less verbose, more flexible and without forcing everyone to write immutable code (regardless what is our opinion about mutations, it's not something that should prevent a library from working).

And there was the time that developers started to notice it. As their projects were getting bloated by thousands of Redux reducers glued together into a single Super-Store and they hit its limitations coming from over-constrained architecture, more people started to switch to Mobx and build some high-quality, highly-maintainable, yet concise and elegant architectures.
It enabled developers to have a clear separation of concerns, stateless, functional components, and organized way of keeping their logic in shape.

Context API

React tried to design its own, scalable way of managing state and released the first version of the now-legacy Context API (but it didn't get much traction) and then (in React v16.3) another (current) version.

Just look at the syntax to reuse state of two objects in the component (which contains a single line of real code and 10 lines of boilerplate to enable state reuse):

import ThemeContext from '../../../Context/ThemeContext';
import UserContext from '../../../Context/UserContext';

<ThemeContext.Consumer>
   {theme => (
     <UserContext.Consumer>
       {user => (
         <ProfilePage user={user} theme={theme} />
       )}
     </UserContext.Consumer>
   )}
</ThemeContext.Consumer>

So React team had a problem now.
For some reason, they didn't wanted to keep React doing what it was designed to do (and what it does very well) - being the "V" in the MVC.
They wanted to take over State Management.

But they had this ass-ugly Context API loaded with Render-Props boilerplate just to make it work.
And it was so bad, it was so against React's own goal of component reuse, that in the same documentation page describing the Context:

Context provides a way to pass data through the component tree without having to pass props down manually at every level.

They had to add a disclaimer saying:

Apply it sparingly because it makes component reuse more difficult. If you only want to avoid passing some props through many levels, component composition is often a simpler solution than context.

Which essentially says - here is the solution for the problem of passing props via multiple layers, yada, yada, yada, but you shouldn't use it only if you want to solve the problem of passing props via multiple layers. Use it only when you are desperate and on your own risk (you were warned).

Hooks

So to fix the syntax problem the React v16.6 came about.
With hooks.
A minor feature with major consequences.
Over-hype that could be beaten only by Cyberpunk2077, Luna and NFTs.

But it was a game changer when it comes to adoption.
When React team said that Hooks solve the issue with clutter of render props and HOCs around the code - they meant mainly the problems caused by their Context API (the other reason was to get rid of the classes to reduce the effort of maintaining two ways of achieving the same thing - which is totally understandable).
And it does make the syntax cleaner.

Yet the problem persists:
React team keeps trying to solve problems that are already solved much better by others (Mobx is just one of them) instead of focusing on what was the mission which let React to capture hearts of millions of developers in the first place - the efficient, declarative management of DOM.

I do not claim that React doesn't do its primary objective right (I think it does), but by pushing its own inferior solutions for State Management instead of collaborating with better solutions available in the open-source to refine them for the whole range of use cases, they are just creating chaos both in juniors' minds and during interviews.

I'm happy to listen to your opinion and I do care about it so regardless if you agree or not, please share it.

Thanks for reading.