I'm a Redux maintainer, and that post is utterly and completely wrong in every way.
What Dan Abramov showed at JSConf Iceland was a pair of demo apps that illustrated upcoming improvements in React related to async rendering and data cache handling. Those features have no bearing on whether or not you use Redux, and are certainly not "replacements" for Redux. The linked tweet from Kent C Dodds was a joke tweet in a joke discussion thread, and the author of that site has repeatedly shown that either they don't understand the React world, they are very bad at writing and researching, or that they're just flat-out trolling.
There's certainly been plenty of discussion lately about when it's appropriate to use Redux, and I'd agree that many people are told to use it blindly without understanding what the tradeoffs are. It's also true that the new React context API (available in the upcoming React 16.3 release) means you won't need to pull in Redux _just_ to avoid "prop-drilling" data all the way down the tree.
However, Redux is absolutely not deprecated and not being replaced, and the React team isn't in charge of Redux anyway. Dan Abramov and Andrew Clark, the co-creators, are both now part of the React team, and are no longer active maintainers - Tim Dorr and I are. We _do_ still talk a lot about what the future plans are for Redux, and in fact right now we're working on updating the React-Redux library so that it properly works with the "async rendering" capabilities once those are released (see discussion [0] and an early WIP PR I filed yesterday [1] ).
With that said, in many circles I frequent there seems to be growing consensus that Redux just isn’t that useful, and in many cases ends up being a tar pit of boilerplate code that slows down development. Any project complex enough to require Redux should have enough talent on hand to basically write their own version of Redux for their purposes. Redux is such a small library and not enough people seem to be looking under the hood to realize there’s nothing magical about it.
If this is a growing perception amongst the developer community, it’s only a matter of time before it begins to impact the Redux’s relevancy.
I'll agree with the "nothing magical" statement, but I disagree with most of the rest of that comment.
Certainly there's nothing "magical" about Redux. After all, the core `createStore` function can be written in about 25 lines if you leave out error handling, and the entire core lib in about 100 lines [0]. React-Redux does have a ton of optimization work internally, but conceptually it's pretty simple too - components subscribe to the store, call getState(), extract what they need, and re-render [1]. And that's the great thing: Redux is, as its tagline says, "a _predictable_ state container" - there _is no magic_ involved.
What a lot of people don't seem to realize is that the Redux core is a _starting point_. One of my favorite quotes is:
> "Redux is a platform for developers to build customized state management for their use-cases, while being able to reuse things like the graphical debugger or middleware"
We encourage Redux users to use whatever abstractions are appropriate for their own applications, including writing their own. In addition, Redux was designed from the ground up to be extensible [2]. As a result, the Redux ecosystem has exploded. My Redux addons catalog [3] lists somewhere around 2000 Redux-related libraries, utilities, and tools, ranging from action/reducer generation utils to side effects management addons to abstractions for fetching data from REST APIs.
I've seen dozens of "Redux, but.." knockoffs. Most of them wind up throwing away the key design decisions that make Redux special. In particular, the concepts of plain object actions and reducer functions are what truly enable time-travel debugging and easy serialization of state.
My current estimate is that somewhere between 50-60% of React apps currently use Redux. Redux has gained adoption in the Angular, Ember, and Vue communities as well, and inspired dozens of similar libraries, like NgRx, VueX, and more.
Sure, I expect that some of that "market share" will slip over time, especially with the release of the new React context API soon. But, I also feel safe in saying that Redux will be around for a long time.
This article puts a pretty hard spin on what actually happened: Dan Abramov did not announce a "replacement for Redux", nor is he developing a "Future Fetcher" library. The React team is working on a feature that defers state updates until an asynchronous operation is finished, but we don't know how it'll fit into existing state management solutions.
https://react-etc.net/entry/rip-redux-dan-abramov-announces-...