What is the difference between ReactDOM.render and createRoot in React 18?

What changes in React 18 when you switch to createRoot

React 18’s modern root API changes the rendering contract, not just the import path. With createRoot, React can apply automatic batching more broadly and schedule work with concurrent rendering behavior, which means updates may be grouped or deferred differently than they were under the legacy root. That is why existing code can behave correctly but still surface timing-sensitive differences.

The practical distinction is that ReactDOM.render keeps your app on the older root model, while createRoot opts it into the new one. For a team, this is less about syntax and more about execution semantics: state updates, effect timing, and UI responsiveness can all look slightly different, especially where code relied on synchronous rendering assumptions.

One useful way to think about it is that ReactDOM.render preserves legacy behavior for older applications, while createRoot is the entry point for React 18 features that improve scheduling flexibility. If an app or test suite depends on immediately visible DOM updates after every state change, the new root can expose those assumptions.

Why the rendering model matters for state, timing, and tests

The main operational difference is not visual output but when React chooses to commit work. Automatic batching can reduce unnecessary re-renders, but it can also change the moment at which intermediate state becomes observable. Components that read layout, depend on chained updates, or coordinate with non-React code may need closer review because the timing contract is now more modern and less rigid.

Testing is often where this becomes obvious first. Assertions that passed because updates happened synchronously can become flaky when a render is scheduled differently or batched across event boundaries. The fix is usually to assert on the final committed UI state, not on an assumed intermediate step, and to update tests so they match the new render lifecycle rather than the old one.

Migration also tends to surface code that accidentally depended on render ordering. That includes patterns like reading from the DOM immediately after setting state, assuming one update will flush before the next line runs, or mixing React state with imperative code that expects older synchronous semantics. Those patterns are not always broken, but they are the first ones to verify.

What teams should verify before and after migration

Decision rule: If you are starting a new React 18 app, use createRoot. If you are upgrading an existing app, migrate deliberately and validate timing-sensitive paths, because the behavioral differences are real even when the UI looks unchanged.

What to verify: Focus on components that depend on sequential updates, effect timing, portals, external subscriptions, and test cases that assert render order or immediate DOM state. Re-run interaction-heavy flows and confirm the app still behaves correctly when multiple updates are batched into one commit.

Common mistake: Treating the change as a mechanical replacement of one API call with another. The root change is an application-level behavior change, so the safer approach is to review assumptions about synchronous rendering, then update tests and any imperative integration points that depend on it.

Practitioner takeaway: The migration succeeds when the app is functionally stable under the new scheduling model, not when the import change compiles, so timing-sensitive code deserves the first review.

Related resources from NHI Mgmt Group

• What is the difference between patching React itself and patching frameworks that bundle React Server Components?
• What is the difference between hosted login and embedded login in a React authentication flow?
• What is the difference between NHI and machine identity?
• What is the difference between an identity, a credential, and a secret?