Suggest an editImprove this articleRefine the answer for “Concurrent Mode”. Your changes go to moderation before they’re published.Approval requiredContentWhat you’re changing🇺🇸EN🇺🇦UAPreviewTitle (EN)Short answer (EN)**Concurrent Mode** was an early, experimental React rendering mode that tried to make rendering asynchronous at the core level, letting React pause, cancel, and resume rendering parts of the UI without blocking the main JavaScript thread. **Key point:** it was renamed to "Concurrent Features" because a "mode" implied turning it on or off and broke compatibility with older libraries, whereas since React 18 the same capabilities (Transitions, Suspense, Streaming SSR, etc.) are enabled selectively on top of a single concurrent engine through `createRoot()`.Shown above the full answer for quick recall.Answer (EN)Image## 1. What "Concurrent Mode" was (historically) Before React 18, the React team was experimenting with a new rendering engine: **Concurrent Mode**. It was an *experimental mode* that completely changed **how React renders the component tree**. > The goal of Concurrent Mode: > make React **asynchronous**, so it could **pause**, **resume**, and **cancel** rendering parts of the UI, > without blocking the main JavaScript thread. ### In simpler terms: React wanted to "think ahead", render parts of the interface in the background, and show them once they were ready. This opened the way to: - smooth transitions between screens, - loading data without the UI "jittering", - better responsiveness under load. ## 2. The problem with the old approach In React 17 and below: - rendering was **synchronous**: once React started a repaint, it had to finish it **entirely**; - the UI could "freeze" while React rendered large lists or heavy components; - there was no flexible way to manage priorities (for example, distinguishing "urgent" updates from a "background" one). Concurrent Mode was supposed to solve this. ## 3. What Concurrent Mode could do When it appeared (in React 16.8 - 17, in experimental builds), enabling the mode looked roughly like this: ```javascript ReactDOM.createRoot(rootElement, { concurrent: true }); ``` This activated a new "asynchronous" rendering engine, where React could: - pause a render (pause), - cancel an intermediate result (cancel), - resume it (resume), - show a *partially ready UI* (partial hydration, streaming SSR). ## 4. Why "Concurrent Mode" was abandoned The React team realized: a "mode" implies that it can be **turned on or off**, and that **breaks the ecosystem**: libraries need to know which mode they are running in. Many developers were afraid to turn on "Concurrent Mode", because it **broke compatibility** with older libraries that were not designed for interruptible rendering. > A quote from the React Blog: > *"Concurrent Rendering is not a new mode that you turn on - it's a set of features that you can use when you need them."* ## 5. The move to "Concurrent Features" With the release of **React 18 (March 2022)**, the React team changed its philosophy: > No more **separate mode**. > Instead: **a set of capabilities (features)** that are turned on **as needed**. Now everything works **within a single engine**: the new concurrent-rendering-core. And concurrent capabilities are activated automatically if you use a modern API. ## 6. What "Concurrent Features" now includes Here are the main **features** based on Concurrent Rendering: | Feature | What it does | |---|---| | **Automatic Batching** | React combines several `setState` calls into one render, even in asynchronous contexts | | **Transitions** (`useTransition`, `startTransition`) | Let you defer low-priority updates (for example, filtering, search) | | **Suspense for Data Fetching** | Lets React "wait" for data (a Promise) and show a fallback UI | | **Streaming SSR** (`renderToPipeableStream`) | Lets the server send HTML in streams, without waiting for the whole page | | **Selective Hydration** | The client hydrates only the parts of the page that are already visible / needed | | **useDeferredValue** | Lets you "defer" computing unimportant data so it doesn't block rendering | All of these features **work on top of a single concurrent engine**, but they are **turned on selectively**, when you use the corresponding APIs. ## 7. How this is turned on now Before: through a "mode": ```javascript ReactDOM.render(<App />, root); // regular ReactDOM.createRoot(root, { concurrent: true }); // Concurrent Mode (old) ``` Now: simply through the new API: ```javascript import { createRoot } from 'react-dom/client'; const root = createRoot(document.getElementById('root')); root.render(<App />); ``` That's it: React now uses the concurrent renderer by default. No "modes", "flags", or "breaking changes". ## 8. The main difference in philosophy | Before (Concurrent Mode) | Now (Concurrent Features) | |---|---| | A mode (turned on/off) | A set of capabilities (turned on automatically) | | Required full library adaptation | Compatible with older libraries | | Could break behavior | Safe and gradual | | Experimental | Stable and production-ready | | Activated manually | Works through `createRoot()` | ## 9. Summary > **Concurrent Mode** is an early experiment > where React tried to make rendering "asynchronous" at the core level. > > **Concurrent Features** is a modern, stable implementation of the same ideas, > but in the form of **flexible APIs** that can be turned on as needed. ### In short: | Term | What it means | Status | |---|---|---| | **Concurrent Mode** | The old experimental mode, fully concurrent rendering | Removed, not used | | **Concurrent Features** | Modern, stable capabilities (Transitions, Suspense, Streaming SSR, etc.) | Used since React 18+ | | **Concurrent Rendering** | The internal mechanism underlying all of these capabilities | Always active with `createRoot()` |For the reviewerNote to the moderator (optional)Visible only to the moderator. Helps review go faster.