Why Redux Makes You a Better JavaScript Developer
Being OOT and throwing in unpopular opinion:<p>Redux fails in recreating the success of elm architecture. Without the static typing of elm, it ends up being painful to use.<p>Redux drives inexperienced developers to put everything into the store, making it a god-object. See: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=14669980" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=14669980</a><p>Redux middlewares allow changing return type, which makes it hard to implement static typing to it.<p>Redux without middlewares needs additional code to work with static typing. See: <a href="https:&#x2F;&#x2F;github.com&#x2F;piotrwitek&#x2F;typesafe-actions" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;piotrwitek&#x2F;typesafe-actions</a><p>Redux expose actions and reducers to developer, which is a state management mechanism that usually are written the same over and over again.<p>I sound harsh on it, but I want devs around the world to not go through the pain of using Redux on large scale project involving a lot of people.<p>Redux is good for education. It introduce the concept of immutability, higher order function. I learn a lot from it. Nevertheless, it is a pain to use on big projects.<p>React&#x27;s setState is friendlier to devs. Unstated <a href="https:&#x2F;&#x2F;github.com&#x2F;jamiebuilds&#x2F;unstated" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;jamiebuilds&#x2F;unstated</a> (but not unstated-next), is a detached version of React&#x27;s setState with additional `.subscribe` method and Promise as return. It is very good in both developing and communicating business flow. UnstatedContainer method can be treated as counterpart of Redux&#x27;s action.<p>What is missing now from the client-side web development is an in-app event library. Usually people would put domain-objects to Redux to solve the inter-component communication. This is, against the functional programming (which promotes immutability, higher order functions), introducing the possibility side-effect.<p>In-app event library should replace this behavior so that messages can be passed through events from one component to another that resides on different component-tree, which may want to act differently. This is some sort of implementing mini kafka&#x2F;rabbit-mq-like behavior inside the your web app with minimum resource required.