Virtual DOM与Real DOM操作疑问：React渲染及DOM重绘问题

1. Does React use native DOM APIs to render elements to the Real DOM? #

Absolutely—React doesn’t conjure elements into the DOM out of thin air. Under the hood, it relies entirely on native browser APIs like document.createElement, appendChild, removeChild, and others to create and manipulate real DOM nodes.

Here’s a simplified breakdown of how it works:

• When you call ReactDOM.createRoot(document.getElementById('root')).render(<App />) (React 18+), React first converts your JSX into a Virtual DOM tree—a lightweight JavaScript object representation of the DOM structure.
• It then traverses this Virtual DOM tree, calling document.createElement for each element, setting attributes with element.setAttribute, and appending child nodes with appendChild to build out the real DOM structure inside your root container.
• For updates (when state or props change), React calculates the difference between the old and new Virtual DOM trees (this is the "diffing" process), then only applies the necessary changes to the real DOM using those same native APIs—no full re-render of the entire tree.

You can even verify this by inspecting the browser’s call stack during a React render; you’ll spot those native DOM methods being invoked behind the scenes.

2. Real DOM Performance & Repainting in Simple Scenarios #

Let’s bust a common myth first: modifying the Real DOM does NOT automatically repaint the entire DOM. Browsers are highly optimized to only re-render the parts of the DOM that actually change.

a) Does modifying a simple element repaint the whole DOM? #

No. For example, if you run this vanilla JS code:

document.getElementById('my-paragraph').textContent = 'Updated text';

The browser will only repaint that specific <p> element (or trigger a small reflow if the text change affects the element’s size). The rest of the DOM remains completely untouched.

The "Real DOM is slow" narrative stems from unoptimized manual DOM operations—like repeatedly appending elements in a loop without using a document fragment, or making hundreds of individual DOM changes that trigger multiple reflows. It’s not the Real DOM itself that’s slow, but inefficient use of it.

b) Is Virtual DOM unnecessary for simple HTML/script scenarios? #

For extremely simple use cases (e.g., a single button that toggles a text value), yes—using native DOM APIs directly might be slightly faster, since you skip the Virtual DOM diffing overhead.

But here’s the catch: even simple apps tend to grow over time. React’s Virtual DOM provides consistency, predictability, and abstraction. You don’t have to manually track which DOM nodes need updating when state changes; React handles that for you. For complex applications with many state variables and nested components, this abstraction saves you from writing error-prone manual DOM code and ensures efficient updates.

内容的提问来源于stack exchange，提问作者Liam