This reminds me of a recent article by the author of Redux, who wrote ["You might not need Redux"](<a href="https://medium.com/@dan_abramov/you-might-not-need-redux-be46360cf367" rel="nofollow">https://medium.com/@dan_abramov/you-might-not-need-redux-be4...</a>). It was refreshing how he emphasized that Redux is just an implementation of a design pattern (or a composition of a few), that it's not necessarily "the solution". If another state management library works better for some applications, then use that instead.<p>"Overhyped" implies that its popularity is not worth its value. It's clear that it has proven its value to a majority of developers working with React. Especially as applications grow larger, I've found that using Redux provides an intuitive pattern for sane state management.<p>It does have its pain points (verbosity, async actions) but there's a plethora of libraries one could choose from, depending on need and preference. Since the core functions are so simple, they can be adapted as needed - for example, in a recent project I wrote a wrapper (~20 lines) to extend actions and reducers with namespaces.<p>An additional advantage of Redux, I think, is that it's becoming widely adopted, so when I look at an open-source codebase built on React + Redux, it's so easy to understand the application architecture.