I am also MVC grown. I believe we'll need to dive into FLUX to understand full picture.
My understanding is that as HTML templating moved to browser (with Backbone or Angular frameworks), this single page application can provide much better interactive experience to user than traditional web app with server side tamplating. For example you application can hold the state of application and base on some user action update various HTML elements instantly without roundtrip to server.
But handling state turned to be complicated with Backbone or Angular 1.x (not sure how Angular 2 handles it so far), because MVC or MVx patterns couple data model with view via controller or directly. But what if you want to react in other views on state change of the this model? Angular 1 provides some features for handling this, but you can easily shoot yourself into foot with nested controllers or nested scoping.
So FLUX movement is trying to address this and introduced this unidirectional flow:
----> Dispatcher ----> State Store ------> Component(View) -----> Dispatcher
Component or various components are subscribed to certain model state changes and sends user actions to Dispatcher. Dispatcher based on these actions updates model (State store), which can again trigger one or more View updates. Dispatcher action doesn't have to be triggered from component only. It can be done from server also.
This way sharing the state(models) between views is much easier.
Now, React.JS is component from above diagram. Fundamental part of is that it doesn't mutate DOM directly, but uses shadow DOM concept, where it gathers differences against previous DOM state and applies only them. So you can re-render a lot or even all of your components, without worrying about performance mostly.
Consequence of all this is that React component have these concerns:
- Needs to use Shadow DOM to mutate HTML
- Needs to subscribe to model (State Store) changes
- Needs to dispatch actions against State Store
React ecosystem is evolving rapidly and there are attempts to enhance this. For example look how Dan Abramov (creator one of the hottest State Store libary called Redux) separates these concerns into so called Presentational and Container component types.
So long story short, it looks as step back at first, but if you dive deeper, you may gain much bigger maintainability benefits in long run in form of true decoupling model from view.
BTW, I recommend to check this video on FLUX vs MVC.