I hope I can provide some insight for two of your points, though I'm not the most experienced dev in the world: Redux: Though it is complicated to grasp the te

I hope I can provide some insight for two of your points, though I'm not the most experienced dev in the world: Redux: Though it is complicated to grasp the tenants of redux, and it sometimes does involve writing a lot of boilerplate, it adds value by containing the entire state of a web app in a single object. To achieve a change in state, you dispatch an action that should describe the change being made. When an action is dispatched, a reducer is called on the existing state object, which returns a NEW object representing the new state for the web app. You do not modify the existing object. By representing all state in a single object, dispatching actions (that should describe the change occurring), and using reducers to return a new object to represent the state, the state of complicated web apps should be much easier to understand and reason about. By using tools like the redux dev tools, it is even theoretically possible to 'time travel' through a users journey on your site (if, say, they hit a bug you are having trouble reproducing). You can see every action they dispatch and how it modified state. Immutable: In my experience, Immutable.js is often used in combination with redux to insure that you are not inadvertently modifying the state object. Inadvertent in place modifications happen very easily, and it can be difficult to write good tests with basic redux to catch all these unwanted behaviours. Using immutable extensively prevents these unintended modifications, and confirms you are returning a new state object rather than modifying the existing one. If anyone has any issues with what I've written, please let me know. I'm newer to JS/React/Redux.