Redux vs. Context

In an earlier post I wrote, I remarked on how many developers in the React community feel that Redux is an overkill, an antipattern, and so on. And so, they’ve started developing in the Context API instead.

In fact, the narrative now is that Context is going to “kill” Redux.

Is it?

Well, the thing is, Context is really simple and works well with the new Hooks API, but lurking in the beauty is a major concern: performance.

You see, despite the powerful modern processors and gigs of RAM, computer resources are still limited. In React, this becomes important because React has to compare the virtual DOM with the real DOM and build the necessary markup and create new nodes. And the more number of times per second it has to do this work, the slower your app will be.

The problem with context is that it triggers a re-render of the full DOM tree every time even one of the values changes. This “rendering” behavior is fundamental to React, but of course, unless you’re a senior dev and working on a really critical app, it doesn’t matter too much. Which is why it gets left out of these conversations.

For most projects and developers, however, the ease that Context brings is more than enough to overlook any performance issues. And for that reason, they will use Context over Redux, and yes, for them, it makes a lot of sense.

Me? I can’t overlook the fact that Redux is a really important part of the React ecosystem, gives performance free out of the box, and is the default (only?) choice for good teams building large, performant UIs, so I’ll continue to use Redux as much as I can.