Reamain part of previous post reconciliation in React.js

CodeSmithNazim — Wed, 15 Jul 2026 14:56:17 +0000

second part:

The Clash of Two "Renders"

The biggest culprit is that the word "render" means two completely different things in computer science, and React tried to use both at the same time:

Browser Rendering: This is when the browser engine calculates layouts, builds render trees, and paints pixels on your screen.

React Rendering: This is when React calls your component functions to build a JavaScript object tree (virtual DOM) in memory.

Because the browser's process was already called "rendering," React's creators used the same word for their virtual DOM creation. For years, when the docs said "React prevents unnecessary renders," developers read that as "React prevents my components from running their JavaScript." It took years for the community to realize we were talking about two entirely different concepts!

The 2013 "Marketing Pitch"

When React was first introduced in 2013, the web development world was dominated by frameworks like jQuery, Backbone, and AngularJS. In those frameworks, developers had to manually update the browser DOM, or the framework would heavily slow down the browser by sweeping the entire real DOM on every change.

React's biggest selling point was "Stop worrying about manual DOM updates." Just write your UI declaratively. The Virtual DOM will magically do the work of reducing renders."

To sell this idea simply to a skeptical developer audience, the creators packaged the message into "We minimize rendering." It was a highly effective marketing pitch, even if it technically blurred the lines between the JavaScript render phase and the browser paint phase.

The React Team Literally Changed the Docs to Fix This!

The confusion grew so massive that when the React team rewrote the official documentation from scratch (moving to the modern react.dev), they explicitly rewrote the guide to fix this exact misunderstanding.

If you look at the modern "Render and Commit" section of the official docs, they now explicitly separate the process into three distinct steps—Trigger, Render, and Commit—and they added an "Epilogue" just for the browser:

"Epilogue: Browser paint

After rendering is done and React updates the DOM, the browser will repaint the screen. Although this process is known as "browser rendering," we'll refer to it as "painting" to avoid confusion throughout the docs.

They literally had to invent their own terminology ("painting") to stop developers from confusing React's in-memory calculations with actual browser screen updates!

The Verdict:-

When people say "reconciliation decreases the amount of things re-rendered," they are usually using "re-render" as a layman's term for "affecting the actual browser screen."

If you could understand the above two posts, then you understand React's core architecture better than many developers who have been writing it for years.

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

CodeSmithNazim — Wed, 15 Jul 2026 12:25:52 +0000

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:

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.

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!

DEV Community: CodeSmithNazim

Reamain part of previous post reconciliation in React.js

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