In React 19, does "concurrent rendering" mean React renders components in parallel on several threads or inside a Web Worker? Explain what actually happens on the main thread.
answer
- taking turns, not simultaneous
- same main thread as before
- interruptible, never faster
- discarded work is done again
basics
~20 sNo. Concurrent rendering is interleaving, not parallelism. React still renders on the one main thread; it can split a render into slices, yield to the browser between them, and abandon an in-progress render to do urgent work first.
solid answer
~40 sNo — there is no parallelism and no worker involved. Every component still runs on the main thread, one at a time. What "concurrent" means is that a render is no longer one uninterruptible blob of work: React can render part of the tree, hand control back to the browser so it can paint and dispatch input, and then continue — or throw the partial render away and start over when a higher-priority update arrives. The visible effect is that a heavy re-render stops blocking typing and clicking. It is just as important to say what it does not do: it does not make any component render faster, and it does not move rendering off the main thread. Total CPU can actually go up, because work that gets abandoned is done again.
go deeper
Be able to say plainly that concurrent rendering is interleaving on the single main thread, not threads or workers, and that it makes renders interruptible rather than faster.
Explain the mechanism: React renders in slices, yields to the browser between them, and can abandon a partly-built render, while the commit to the DOM stays synchronous.
Show that you know the cost side — abandoned work is redone, so CPU can rise — and that responsiveness gains do not excuse an expensive component whose body cannot be split.
Frame it as a latency-versus-throughput tradeoff the team is choosing, and be ready to say when the honest fix is less work per update or moving computation to a worker rather than more prioritization.
## The word "concurrent" is doing precise work here Concurrency and parallelism are different claims. Parallelism means two pieces of work are executing at the same instant, which requires more than one execution context — extra threads, extra cores, a worker. Concurrency only means several pieces of work are *in progress* over the same period, taking turns. React's concurrent renderer is the second kind, and nothing more. Since React 19 there is no legacy synchronous root left in the DOM renderer at all: `createRoot` (and `hydrateRoot`) give you the concurrent renderer, and the old `ReactDOM.render` entry point was removed. ## What actually happens When React renders, it walks the component tree, calling your component functions and building an in-memory description of the result. In a synchronous render it does that whole walk and then commits to the DOM without ever returning to the browser. Under concurrent rendering, an update that has been marked as low priority is rendered in *slices*: React renders some components, decides it has held the thread long enough, stops, and asks the browser to call it back in a later task. In that gap the browser gets to do what it could not do before — paint a frame, run a scroll, deliver a keypress to your input. That is the entire trick, and it happens on the same single main thread the rest of your page runs on. Two of your components are never mid-execution at the same moment. ```jsx function Row({ item }) { // Still ordinary synchronous JavaScript on the main thread. return <li>{item.label}</li>; } ``` ## The second half of concurrency: abandoning work Taking turns also lets React change its mind. If a more urgent update arrives while a low-priority render is only half built, React can throw away the partly-built result and start a fresh render for the urgent update instead. Nothing half-finished is ever written to the DOM — the commit phase, where React actually touches the DOM and runs effects, is synchronous and is not sliced. So the intermediate states live only inside React's memory. This is why the Rules of React matter more than they used to: your component function can be called and thrown away without ever producing visible output, so a render body that mutates something outside itself can have that mutation happen more times than there were visible updates. ## What it buys you, and what it does not It buys **responsiveness**, not **speed**. If filtering a 10,000-row list costs 300 ms of JavaScript, it still costs 300 ms after you make it a transition. The difference is that those 300 ms are now chopped into short pieces with browser turns in between, so a keystroke can be handled after roughly one slice instead of after the whole render. Latency for the *urgent* interaction drops sharply; the total time for the heavy work stays the same or gets slightly worse, because abandoned slices are redone. It also does not remove the need to fix genuinely slow code. React can only stop *between* components — it cannot interrupt the inside of one component function, because ordinary JavaScript runs to completion. One component that spends 200 ms in its own body still blocks the frame no matter how the renderer is configured. ## Saying it well in an interview A clean answer is three sentences: concurrency here means interleaving on one thread, not parallel execution; React achieves it by splitting a render into slices and yielding to the browser between them, and by being willing to discard an in-progress render; and the benefit is interruptibility, not throughput. Candidates who claim workers or threads are usually reasoning from the word alone, and interviewers notice.
- If concurrent rendering does not make anything faster, what measurable thing improves?Input latency. The time between a keystroke or click and the browser painting the response drops, because React only has to finish the current slice before handling the urgent update instead of finishing the whole render. Total CPU spent on the heavy work is unchanged or slightly higher, since abandoned slices are re-rendered.
- Could you move React rendering into a Web Worker to get real parallelism?Not for DOM rendering. Components read and write the DOM through the commit phase and through refs and layout measurement, and the DOM is only reachable from the main thread. You can move pure computation — filtering, parsing, diffing large data — into a worker and post the result back as state, which is usually the practical answer when a render is expensive because of the data work behind it.
saying these in an interview costs you the question
- Says React renders components in a Web Worker
- Claims concurrent rendering makes components render faster
- Thinks two components can render at the same instant
- Believes concurrency removes the need to fix a slow component