[lioeters]

This reminds me of a recent article by the author of Redux, who wrote ["You might not need Redux"](https://medium.com/@dan_abramov/you-might-not-need-redux-be4...). 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.

"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.

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.

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.

[shakiba]

> when I look at an open-source codebase built on React + Redux, it's so easy to understand the application architecture.

That's my point, I believe a library should not imply architecture.