Conquering React Concurrency

Hi, everybody. I want to thank everybody joining us on React Summit 2026 Virtual Track. I'm personally really excited to be a part of this conference and to be a part of this lineup. I've been following React Summit for quite a few years now, and it's really just a privilege to be able to speak here about one of my favorite subjects, which is React concurrency.

So my name is Ariel. I'm a full stack engineer at Factify. I am a public speaker and I am a human intelligence enthusiast, like not many are these days. So I feel like many talks today need to start with a what's in this talk for me, especially with everything becoming irrelevant with a matter of days. And I imagine many of you have heard the news that Meta is starting to capture employees' mouse movements and keystrokes for training large action models. What can we learn from this? What we can learn is that the way users interact with the web is still a blind spot for AI. And this is where a good front-end engineer comes in because although code is commodity, user experience and specifically a great user experience still isn't. So what's in this talk for me? All the things that actually stay relevant. So we still need to know computer science theory and we still need to understand users. And we should still know our toolkits for building a great user experience. And all of these things we are going to be discussing today.

So we're going to split this talk into three sections. So the first section is understanding what is concurrency. The second section is why do we need it? And last but not least, we will discuss how is concurrency implemented in React. So no further ado, what is concurrency? The thing about concurrency is that it is very often mistaken to be parallelism. However, concurrency and parallelism are two very different things. Parallelism is when you are doing stuff at the same time. Here we can see Spongebob cleaning his house in parallel. Is Spongebob advancing faster because he's doing these things at the same time? I would dare say that dusting your carpet at the same time that you're wiping your window is actually making your house messier. So I say Spongebob is getting his house messier every second going by because he's doing these things in parallel. Now, explaining parallelism is really quite easy. Explaining concurrency is more complex. And the best analogy I could think of for concurrency is a small restaurant in California in 1942. This is not a commercial, I am vegan, but I think they are a really great example for concurrency. 1942, Richard and Morris McDonald's redesigned McDonald's, because they want to reduce their expenses and to deliver faster. But they are very limited.

They are limited in technology, they are limited in staff, they have a very small kitchen, but they are very intelligent and very creative. So what the McDonald's brothers did was the following thing. They took their full team for a whole day on a tennis court. And what they were trying to look for was the most perfect flow and design for their kitchen, which would allow their workers to work in harmony in a way that they leverage the work of the workers and that they managed to use as much of the resources of the kitchen as possible. It took them around six hours on this court until they found it. The speedy system. This is basically the invention of fast food. And the speedy system is an architecture. It's a way to design your kitchen and to distribute the work between the different workers so that they can continuously deliver in harmony. Now, this improved their ARR by 200k already on the first year and 200k was a lot of money in 1942. And they also improved performance from 30 minutes to burger to 30 seconds.

Now, the McDonald's brothers would call this speedy system. I call this concurrency, because this is what concurrency is really about. Okay, parallelism is just when you are doing stuff at the same time. But concurrency is an idea. It's a design. It's a way to maximize your current resources in order to continuously deliver. So yeah, things could be happening at the same time. But it's not about running things at the same time. It's about continuously delivering with your current resources. So concurrency is not parallelism. But what is interesting is that concurrency could be used to fake parallelism. And we're going to see how do operating systems leverage concurrency in order to fake parallelism.

Let's say that we have a machine that only has one physical core. And on this machine, we have three processes running. Let's say that in this imaginary scenario, at zero seconds, we have a Visual Studio process that needs to run for six seconds. And then at two seconds, we have a terminal process that needs to run for two seconds. And at five seconds, we have a Chrome process that would need to run for three seconds. But again, we only have one single core, so they can't run at the same time. So we have a few approaches around it.

The most naive approach is what's called the first in first served approach. What first in first served means is that anything that you start working on a process, you need to finish working on it before you move on to the next one and to the next one. And this is a very naive approach. And it's not a good approach for two reasons. The first reason is that you are in a high risk of one process that can monopolize your entire CPU. So imagine if you have an infinite loop in your VSCode process, no other process would ever run. And beyond the risk of one process that can monopolize all of your CPU, the experience here is just terrible because any process besides the first one would experience delays in its kickoff. And when a process experience a delay in its kickoff, what this basically means, the user is clicking something and nothing is happening. It looks like the system is not responsive to the user. And responsiveness is the most important thing in user experience. And we're going to be discussing responsiveness quite a lot today.

So you can imagine operating systems don't use the first in first served approach. They use a concurrent algorithm that's called round robin scheduling. So what is round robin scheduling? For those who don't have a computer bachelor of science, scheduling or time slicing is the idea that you don't run a full process ever. What you do is that you split the work into certain quantums of time. So let's say that in this imaginary scenario, we have a quantum that is a quantum of one second. This means that we slice our time. And every time that we run a process, we run it for one second. And who's orchestrating all of this is the scheduler process. Now the scheduler is a process that its entire reason to exist is to accept tasks as input and return tasks with their future execution time. This means that this is an asynchronous model, because tasks are not executed synchronously, but they are rather passed on for the scheduler to decide when would they run.

The second part of this is round robin. So round robin in English is taking turns. If we talk about round robin from the world of sports, for example, games that are round robin are games where the goal of the game is to allow for as many participants to take part in the game. So if we take this back to operating systems, the idea is that as many processes would take part in the game. So let's look at how would this look like. Every time that we run a process, we run it for one quantum of time. But the interesting thing is what does the scheduler do when you have two processes that need to run. So what the scheduler would always prefer to do is to alternate. So it would alternate and alternate back and alternate and alternate back.

And it doesn't seem really important. And the overall execution time is still 11 seconds as it was before. But we actually did change a lot. Because what we changed was the experience. Now, no process experienced delays in its kickoff. Users don't expect everything to appear immediately, but they just want to know that the system is responsive. They want to get this validation of a spinning loader just to know that their work request is being handled. Now, we took a quantum of one second to simplify things. But in real life, we're talking about single milliseconds. So when the alternations are between single milliseconds, for the human eye, it really does feel like these things are happening in parallel.

So I think we understand what is concurrency, we understand that concurrency is not parallelism, that concurrency is an architecture. It's a way to design your work and to orchestrate it in a way that you can even fake parallelism. And we can move on to the next section of this talk, which is why do we need it? Because I imagine many people are sitting in their homes thinking to themselves, what does any of this have to do with me? Operating systems and McDonald's, I'm just a front end engineer. I just want to center my div. And I'm really sad to be the one to break this to you. But this has everything to do with you. Because when you run code that runs on the browser environment, you are actually facing challenges that are quite similar to the ones that we've seen before. And these challenges kind of split into three groups. So JS, FPS, UPR.

JS, JavaScript. JavaScript is a single threaded language. Now, although you can run JavaScript in parallel in a running environment like V8, for example, when we're talking about rendering, rendering work does happen on the main thread only. So this is very similar to the operating systems example, we can only render one thing, we can only work on one rendering work at a time. The second limitation that we are facing is FPS. FPS stands for frames per second. FPS is basically the way to measure how is motion displayed to the human eye. As a matter of fact, any motion that you see, whether it's a video game, it's the browser, it's an animation, any motion is nothing but a set of images that change so fast that our brain kind of completes the missing information. And the browser works the same way. So this means that the browser is a flipbook, and the browser flips frames every 16 milliseconds. So this kind of connects to what we were speaking about in the operating system, we have a limitation of a quantum of 16 milliseconds.

And the last limitation, but not least is UPR, which stands for users patience rate. Because the thing about users is that users are like toddlers. Sometimes they can be very impatient, and they expect everything to happen now. But sometimes if you give them the spinning loader fast enough, they know that they need to be patient little kids and wait nicely for their contents to appear. And if we try to differentiate when our users patient and where are they impatient, it already depends on how intensive is their interaction with a component.

So when the user is typing or dragging or watching some animation, the user is very impatient. And I resonate, okay, I am a user sometimes, and there is nothing in this world that is more annoying than typing in an input box and not seeing it straight away. But in any other less intensive interaction, as long as you stay responsive, and you give him the nice little spinning loader, the user can wait patiently for around 500 milliseconds.

So let's go over why does our life suck? And why do we need concurrency? Because we are facing a few challenges, we can only work on one thing at a time when we render, we are limited to 16 millisecond timeframes, and we're babysitting a partly impatient toddler. So you might be asking yourself, how is React handling all of this? And the answer is that before React 18, it wasn't. And this used to be very, very frustrating. And this is the source of a lot of things like debouncing.

And the React finally provided us a native way of overcoming these obstacles in React 18. And React keeps releasing more features that are concurrent and that allow us to overcome these types of challenges. So let's look at how things used to work before React 18.

Okay, let's look at this, like these process bars that we've seen before that we have this urgent process and this less urgent process. So when the user used to type the letter R, he expected to see R in the input box immediately. And then he expected to see the set of results for the letter R. Then the user would type the letter E, he would see RE in the input box, and he would see the set of results for RE. But this is not how users work, right? Users are toddlers. Many times, a user would type the next letter before you even finished rendering.

Now, when this time difference is bigger than the frame rate, this causes frame dropping. Frame dropping causes sad users. Sad users lead to unemployed developers. Now, we don't want this, do we? So I think we understand what is concurrency and how we can leverage concurrency in our use case, and why we are actually facing really similar limitations to the ones that operating systems handle, for example.

And I think we can start discussing how was concurrency implemented in React. No, not really. Before we discuss implementation, I want us to make sure that we are all on the same page on how do we see React. Because React, funnily enough, is not reactive. Let me explain. Let's look at this React snippet. We have this to do state that is initialized to be zero, and we have this use effect, and in this use effect, we set to do to three, and then we console.log to do. What would this console.log log? It would log out zero. And this is something that React lovers and haters like to look at as if it's a bug, but this is actually a design decision that has been there from day one. When you call set to do with three, you are not updating anything. What you are doing is that you are scheduling an update. And when you stop expecting React to be reactive and you start seeing it for what it truly is, which is a scheduler, a lot of things really easily fall into place. And it means that we are not in control of rendering by default. And the heart and soul of React concurrency and all of the concurrent features are to change this and to allow you to be in control over how is rendering executed, to be able to communicate to React that some work can be prioritized, aborted, or split into smaller chunks so we can stay within our frame rate. I think we can start discussing implementation.

Let's start at the top, literally. What does root.renderApp do? This is a recursive function that creates a tree of React elements. This tree is later on used to update DOM. This is a process that's called reconciliation. So it has two phases. The first phase is the render phase in which we calculate the tree of the props and state. And the second phase is the commit phase in which these changes are committed to the DOM. Before React 16, rendering happened in a synchronous way with a reconciler that's called the stack reconciler. The way the stack reconciler used to work was after the render phase where we would calculate the whole tree, we would stack it up into one single stack to be committed to the DOM synchronously. This was the root of our problems where a user typed something and we can't respond to it. We can't be responsive because we are mid-rendering. And React 16 was the first stepping stone in overcoming this challenge when React introduced this fiber reconciler. What is the fiber reconciler? The idea is instead of stacking up all of our changes into one single stack, we would break this stack into a few smaller stacks. So you can look at these as React fiber, you can look at this as a virtual stack, as a React unit of work. The idea was to leverage React's responsibilities as a scheduler.

And if React is a scheduler, then you should already know what the time quantum is, don't you? Well, I kind of lied because although the browser flips frames every 16 milliseconds, it always saves 6 milliseconds to do some cleaning up work. So we are actually facing a quantum of 10 milliseconds. So the idea is not only that we would be able to split our work into smaller, to execute in smaller chunks, but to also be able to say, hmm, this is less important, this can run last, and to be able to prioritize. So these four, suspense, use transition, use deferred value, and activity, are building blocks to be able to control over React rendering. And they split into these two groups.

So the first group is about prioritizing work. And the second group is about chunking work. And activity kind of falls into both groups. We're going to see it later. Let's start with understanding suspense, which is the main building block of React's concurrent model and really the first component released in this domain. So suspense is a component that we import from React, and it accepts a fallback property that accepts a render prop, and it accepts children. And it looks like this fancy loader.

But when you see what happens behind the scenes, it's really quite fascinating. So when you render a suspense boundary within your React tree, what really happens is that suspense renders its fallback property as its parent, and it renders its children as its children. But the interesting thing is that suspense itself is not a component. It is a hole. Suspense is actually plucking a hole in this tree. It is our way to break virtual stacks into a few smaller stacks. This mechanism is what allows us to break rendering so we can easily stay within our frame rate, because you don't need to render the whole tree at once, but you can otherwise just render small chunks of it.

So use transition and use deferred value. These are hooks that allow us to define background rendering. I will explain shortly. Let's just look over at the syntax quickly. Use transition is a hook that returns us a tuple with an is pending flag and a start transition callback. Start transition is a callback that accepts a callback. Use deferred value, on the other hand, is a hook that accepts a value and returns its value. So what does this mean? This means that everything that happens within a star transition, all of these state updates do not happen synchronously on the tree, but they actually happen on the background in a way that is not blocking user interaction. Same thing for use deferred value. So use deferred value returns us a value that everything that is dependent on it. So this deferred tab, if it is passed on as a prop, or it is in a dependency array, all of these state updates that depend on it are also happening in the background in a place that doesn't block user interaction. So let's first see what does this solve, and then we will see visually how does this really happen under the hood because I feel like it's the best way to understand. So the idea is to solve what we started this talk with, that we had the problem that the user types that there are. And then we have some long rendering work. And if the user types something else, we would prefer to be responsive to the user than to keep rendering our work. So use deferred value and use transition allow us to abort what we were doing. This is the meaning of something that is rendered in the background. It is also abortable, and we can respond to the user immediately and start rendering our new RE input box.

So the way this works is that what we used to call the React tree is actually what's called the current tree. And the background is actually another tree, we have another tree that is called the work in progress tree. And this work in progress tree is not visible to the user, and it is rendered whenever we have a transition. So the idea is that when we have transitions, the current tree is referenced by the work in progress tree and everything that the work in progress tree renders in a way that the user doesn't see it. And only when the rendering is completed, then the current tree would start pointing at the work in progress tree. So we get to reuse the work that we already did. Now, why do we need this? We need this because if a user interacts while we are rendering, he doesn't see the work in progress tree, and then we can just abort what we were doing and copy off again. So the user would see our results only if we successfully finished rendering them. And in any other case, we can just abort them because it wouldn't cause flickering in the user's eyes.

And let's talk about our last addition to this current stack, which is the activity component, which is a newer from React 19. The activity component is a component that we import from React, and it accepts a mode property, which is currently or visible or hidden.

The activity component is a component that we import from React, and it accepts a mode property, which is currently or visible or hidden. This is an alternative to the previous pattern of conditional rendering. The problem with the latter was the unmounting of components and the loss of state and props. Previously, state management or React context was used to overcome this, but activity provides a more elegant solution. Activity has two modes: visible and hidden, with hidden mode rendering content in a suspense boundary, maintaining state and props without being visible.

React concurrently features building blocks include use transition and use deferred values for work prioritization and abortable tasks. Suspense breaks work into smaller loads for a better user experience fitting within frame rates. Activity combines features to control chunking, prioritization, and rendering background tasks. Concurrency understanding, its necessity in frontend, React implementation, and tools for modern applications are discussed comprehensively.

The high priority content is rendered first, while hidden content is rendered later without losing state or props. This eliminates the need for unnecessary state management solutions. The discussion covers the importance of concurrency, its frontend application, React implementation insights, and tools for building exceptional user experiences. The React Summit production is acknowledged, thanking the audience for their participation.