I'm a Redux maintainer. There's been a lot of confusion, claims, and misinformation about Redux going around lately, and I want to help clear things up.
Originally published on my blog at blog.isquaredsoftware.com as part of my “Blogged Answers” series .
TL;DR
Is Redux dead, dying, deprecated, or about to be replaced?
No.
Are there situations where you don't need Redux?
Sure, but that's always been true.
A Longer Explanation
There's been a whole slew of comments and articles lately that boil down to people asking "Is Redux dead?", or asserting that "Tool X replaces Redux". I'll recap several sources of confusion, and explain what's actually going on.
"Redux is Overused"
Where's this coming from?
Redux has been around for almost three years. In "JS library years", that's like... forever :) It got very popular very quickly, and as a result, a lot of people were told they had to use Redux, without actually understanding the tradeoffs involved and when it actually makes sense to use Redux. So, there's been some inevitable backlash, and people have looked for alternatives, including adopting other state management libraries or creating their own.
As part of that, there was a wave of tweets about a month ago about how Redux was being overused. One in particular was from Cory House, a well-known author/teacher in the React community. That tweet and various others got heavily retweeted, and the ensuing discussion ricocheted around Twitter for a while.
Clearing the Confusion
The Redux maintainers (first Dan Abramov and Andrew Clark, now Tim Dorr and myself) have always said that you might not need Redux. There are excellent reasons to use Redux, but it may not be the best fit for your situation. Like any tool, it's important to understand the tradeoffs and benefits before deciding to use something.
I've seen plenty of comments amongst the Twitterati that people have opted to move away from Redux to something else. But, at the same time, my own estimates are that somewhere between 50-60% of all React apps use Redux, plus all of its usage with other JS frameworks like Angular, Ember, and Vue, and that is a userbase that isn't just going to disappear overnight. (There's also a big gap between what gets chatted about at lightning speed on social media, and what people are actually doing in "the real world".)
It's also worth noting that Redux is not owned by Facebook - it's a separate open-source project. Both of its creators (Dan Abramov and Andrew Clark) now work at Facebook, but Tim Dorr and I have no affiliation with Facebook at all. We talk with the React team to help coordinate future plans, but Redux doesn't belong to them.
"The new Context API can replace Redux"
Where's this coming from?
React 16.3 is introducing a new stable version of the context
API, which is intended to replace the old unstable API. Context is specifically intended for the use case of passing data to deeply nested React components. That's one of the reasons why some people have chosen to use Redux, and so there's been claims that the new context API will replace Redux.
Clearing the Confusion
Yes, the new context API is going to be great for passing down data to deeply nested components - that's exactly what it was designed for. If you're only using Redux to avoid passing down props, context could replace Redux - but then you probably didn't need Redux in the first place. Context also doesn't give you anything like the Redux DevTools, the ability to trace your state updates, middleware to add centralized application logic, and other powerful capabilities that Redux enables.
"GraphQL can replace Redux"
Where's this coming from?
Somewhat similarly, there's been a lot of noise around GraphQL and the Apollo Client. There have been articles specifically claiming that "GraphQL will let you replace Redux". Also, Apollo has a new apollo-link-state
addon that can handle client-side state, and there's been discussion that that can also help replace Redux.
Clearing the Confusion
I'd agree that data fetching via GraphQL, and especially with Apollo, will likely reduce or eliminate your data-fetching related Redux code. And again, if that's all you were using Redux for, you probably wouldn't need Redux after moving all the data-fetching handling into Apollo. I'll even go so far as to say that apollo-link-state
could probably handle most of your other client-side state logic, and I think Apollo ships with a DevTools setup of its own. The Apollo team has been doing some pretty neat work, and while I don't like seeing people switch away from Redux, ultimately we all want to build great apps that help our users. But, as with context, I'd say there's definitely use cases where Redux is going to work better than GraphQL + Apollo, and possibly without requiring as much buy-in throughout your architecture. This is especially true if you need to do more than just fetch data or update a couple local state values, like persisting user data through page reloads or implementing complex workflow logic.
"Redux is being replaced by something from React"
Where's this coming from?
Finally, Dan Abramov recently gave a great talk at JS Conf Iceland where he demoed two upcoming aspects of React's "async rendering": time-slicing will allow React to split up update calculations for smoother updates, and "React Suspense" will allow deeply nested components to delay their rendering until fetched data is available. Unfortunately, shortly after the talk, a site known for writing misleading and poorly-written articles about React put up a post claiming that "Dan Abramov announced a new 'future-fetcher' library that replaces Redux", and linked a tweet by Kent C Dodds with that statement as evidence.
Clearing the Confusion
One of the problems with social media is that it's easy for misinformation to spread quickly. And especially in this case, because that widely-spread article about Dan announcing a "future-fetcher" library was completely and utterly wrong! Dan's announcement was purely about async React capabilities, and had nothing to do with Redux. In addition, Kent's tweet about Redux being replaced was literally a joke tweet in a joke Twitter "live-commentary" thread about the talk. The article was either a complete misunderstanding of the React ecosystem, or a deliberate attempt to spread confusion and FUD.
The Future of Redux
As a Redux maintainer, I can assure you that Redux isn't going anywhere. The Redux core library is stable, and we've actually got a 4.0 beta release available. Despite the major version bump, it's really just about cleaning up some edge cases and improving the TypeScript typings. Besides that, the Redux ecosystem is thriving.
The real interesting near-future work is around the React-Redux library. We're going to be updating it to work better with React's async capabilities. We have an open issue for discussion of how Redux will work with async React, and I created a proof of concept PR that updates connect
to use the new context API. There will be more work needed over the next few months, but we're committed to ensuring that React and Redux continue to be a great choice for building applications.
Ready to Learn Redux?
So with all that in mind, it's a great time to learn how to use Redux. As always, I'll close with some links to further resources:
- The official Redux docs. I just updated the README to include a quick list of learning resources, and there's a more extensive list of Redux learning resources that cover many aspects of using Redux.
- I've got a blog post with my suggested list of resources for learning Redux
- My React/Redux links list has an extensive section full of Redux tutorials
- My "Practical Redux" blog tutorial series demonstrates a variety of real-world Redux and React techniques through building a sample application, and I've also created an interactive "Practical Redux" course on Educative.io.
I'd also encourage people to really understand when and why they should use Redux. Some suggested articles:
- The Redux FAQ entry on "When should I use Redux?"
- Dan Abramov's post You Might Not Need Redux, which discusses the tradeoffs Redux asks you to make and some of the benefits you get in return
- My two part post The Tao of Redux, Part 1 - Implementation and Intent and The Tao of Redux, Part 2 - Practice and Philosophy, which look into the history and intent behind how Redux was designed, how it's meant to be used, and why common usage patterns exist.
Learn Redux In Person from Me!
Besides all the articles and posts and links, I'm going to be teaching a series of "Redux Fundamentals" workshops through Workshop.me! I'm excited for this chance to spend a couple days helping people learn exactly how Redux works and how to use it.
My first "Redux Fundamentals" workshop is April 19-20, in New York City, with other workshop locations and dates TBD later this year. Tickets for the NYC workshop are still available! If you're not in NYC, or are already comfortable with Redux, spread the word to someone you know who might be interested! :)
Top comments (13)
Really great post Mark. It's amazing how frenzied people can become sometimes. As someone who was involved in React before Redux and used it a bit but then moved away from JS entirely for a while, I was amazed that when I got more engaged in this world that some people didn't even realize you could user React without Redux. And frankly I had to check that I hadn't missed something myself.
I'm curious though how you think about the lifespan of something like Redux compared to other projects. Backend frameworks seem to stick around forever. What do you think typically shortens the lifespan of frontend frameworks and glue-libraries? Is it innovation, mania, or simply a natural part of the domain?
Client build tools also have a tendency to be short lived or are susceptible to the consistent rumors of their demise.
(Caveat: I barely know what I'm talking about here :) )
Well, backend frameworks come and go some too :) About a year and a half ago, I did a talk on the evolution of web dev technologies, and one of the slides had a timeline of new frameworks and toolkits. It's a mixture of front-end and back-end stuff, but there's a fair amount of churn on both sides :)
I think building client-side apps is uniquely complex in a lot of ways. Browser differences, the limitations of JS as a platform, and the constraints of downloading the entire app every time you load a page make building web apps that work for a large diverse userbase pretty difficult (something I'm sure you've seen for yourself building Dev.to ).
Besides, it's not just web apps. For fun, try counting the number of UI frameworks and data access frameworks Microsoft has put out, or look at the ways that programming on Linux has changed over the years (and all the cruft that's built up as a result). And really, there's a lot of parallels there. An
autoconf.sh
is basically like Modernizr or ababel-preset-env
, and Webpack+Babel are basically a compiler and linker.I think the biggest factors are a combination of:
TL;DR: everyone's figuring it out as we go, and ideas are rapidly cross-pollinating.
I do think that React and Redux are a sort of "local maxima". They're not perfect, but they give you a whole lot better approach than most of what's come before. For something to really displace them, it'll have to be noticeably better in a lot of ways.
I'm just amazed that no one can think themselves out of the Redux rut. All frameworks have some variation on the same theme, no innovation just herd mentality it seems. The two forces that helped me escape the dead weight of Redux were: how my own complex app needs to work and RxJS.
I still don't understand why RxJS and the like didn't catch on.
Well, this is it exactly. Redux is a no brainer, good for simple stuff but gets you stuck in the weeds otherwise. While RxJS requires thought and is the perfect step up for those who dare to think beyond the switch statement.
RxJS has caught on some time ago. Angular has it as a major dependency, Vue has Vue-Rx and the React devs have been all over RxJS for sometime.
I hear you though, what is difficult is unlearning the past so you can be part of the future!
Can you share how you measured this?
Sure. I collected these stats for use in my ReactBoston talk on the Redux ecosystem last September. Specifically, see this slide in the presentation.
Neat, thank you!
I've never used neither React nor Redux but I really liked your post. I think being part (and in your case being a leader) of such a huge ecosystem will make you encounter FUD, inevitably. The very fact that many people are using React and Redux without even being sure if they need all that power it's probably a child of that mentality. Kudos to you and the team for developing such a project and for keeping it relevant.
If Redux won't survive the the test of time and the ecosystem evolution (a Shinkansen basically!!), well..., it happens to the best of projects but there is no need to cut other people's legs because you don't agree with this or that technical decision.
I started programming as a teenager (hello, Object Pascal!) and I'm certainly guilty of having been a smart-ass or spreading FUD in this or that mailing list.
Well, it helps no one.
Good luck for the project!
Ps. I feel like Jeff Atwood's rule about everything being eventually written in JS should be adapted to React 🤣
Maybe a bit off-topic, but hopefully still relevant: I always took React for component-building library and that's how I used it mostly. But there's a really great misconception, especially because novice developers are frequently asking questions "Should I learn React or Angular?" as if those were equivalent.
Great article Mark!
Needed, especially if coming from people directly involved in the project.
I haven't shipped my react redux app yet and it's already absolute. Welcome to front end development! j/k
I'd love it if you wanted to dissect my Redux one line replacement hook... useSync
dev.to/chadsteele/redux-one-liner-...