> Redux was the solution to server side rendering state.

Could you explain what you mean by "server side rendering state"?

Server side rendering mounts your application in the server and sends down html along with an initial state.

The client receives this initial state and uses it with the html to glue together a working UI on the client.

This removes the massive JS bloat into raw html and split JS for each component.

Instead of sending 3MB of JS, you send only the JS needed to render the current page... and send additional JS as a user navigates through your website.

Here's an example with Create React App: https://github.com/cereallarceny/cra-ssr

Okay, but that's an even worse idea than what I've seen Redux used for. Now you're splitting the UI between client and server in a completely custom way, that adds even more complexity. Worse, the performance is likely to be worse because now you're paying the bulk JS load cost of loading Redux AND the latency cost of loading small parts as you go: the worst of both worlds. I doubt this is what the Redux folks had in mind, but if it was, it's even worse than I thought.

>because now you're paying the bulk JS load cost of loading Redux

Gonna have to quantify that. Cause I imagine if you did, you'd redact that statement. Redux is a very straightforwards and SMALL library that handles global state.

Its concept can be difficult to follow at first which may cause some to think it way more complex under the hood than it really is.

> you're paying the bulk JS load cost of loading Redux

Redux is small.

> the latency cost of loading small parts as you go

The components are static JS split into files.

Pop those into a CDN and you get the best of both worlds.

Redux is tiny. And with HTTP2 it's better to send multiple small resources than one large payload, especially when it's JS which will lock up when parsing.