The Biggest Misconception About React Reconciliation (Render vs. Paint)

Hey everyone,

I recently had an "aha!" moment regarding how React handles updates under the hood, and I wanted to share it because I realize a ton of developers (including myself, until recently) trip over this exact concept.

The common mental model is that React Reconciliation compares the Virtual DOM directly to the Real Browser DOM and surgically updates only what changed.

But that’s fundamentally incorrect. React never reads or directly compares the real DOM during the diffing process. It actually splits the process into two entirely separate phases —The Render Phase and The Commit Phase —which creates a massive distinction between Re-rendering and Re-painting.

Here is the exact breakdown of what happens when a single state change affects just 1 out of 100 divs in a component:

1. The Render Phase (Pure JavaScript) When state changes, React calls your component function. It doesn't know which of your 100 divs changed yet, so it has to evaluate the entire JSX block.

The Scope: React re-renders all 100 virtual divs in memory.

The Process: It builds a brand-new Virtual DOM tree and compares it to the previous Virtual DOM tree (JavaScript object vs. JavaScript object).

The Outcome: It spots that 99divs are identical, but 1 div has an update. It flags that single virtual node with an "Update" tag.

Because this happens purely in-memory as JavaScript, it is incredibly fast and cheap.

1. The Commit Phase (The Real DOM Update) This is where Reconciliation does its primary job. It acts as a shield to protect the browser from doing unnecessary work.

The Scope: React completely ignores the 99 unchanged elements.

The Process: It surgically targets the single real browser div associated with the flagged Virtual DOM element and updates only its modified property (e.g., element.textContent = "New Value").

The Outcome: The browser repaints only 1 single div on the screen.

The Conclusion: Reconciliation isn't about stopping React from re-rendering (re-running JS to calculate the UI). It is about controlling the browser's re-painting so that the expensive UI updates are kept to an absolute minimum.

Would love to hear how you guys explain this concept to juniors or if this distinction changed how you approach optimization!
continue reading the rest of this post here

Comments

[Frank]

I've always wondered how React's diffing algorithm impacts paint times - did you find any specific use cases where optimizing for render vs paint made a noticeable difference? I'd love to swap ideas on this.

[CodeSmithNazim]

1. When "Render" Optimization Matters (Reducing JS Execution):
   For this purpose we usually use memo() and useMemo().
   Specific use cases:
   Let's suppose you are taking the input text from the user that changes the state of the component having 50 children components; then definitely if the parent component's state changes, then it'll be re-rendered. I mean, all the 50 components will be re-rendered. We use memo() and useMemo() for getting rid of this resource wastage and unwanted re-rendering.
   E.g., searching for a product or filling out the form.

2. When "Paint" Optimization Matters (Reducing DOM Churn):
   Let's suppose we have 100 lists with Math.random() irregular key attributes; if the state changes, JS rendering will be done, and the new virtual DOM will be made and compared to old one. The painting 🎨 of the browser will be done according to the changes between the old and new virtual DOM trees. As keys' attributes are random, repainting will be done for all 100 lists.
   but if we stabilize the key attribute of all the lists, then changes in state of the component or even if the list amount itself changes, the browser repainting will be done for one, two, or small amount of lists, not all hundred