# Inside the React Virtual DOM

In react first thing that seems alien is Virtual DOM, and had kept us thinking what exactly it is? How does it work under the hood? And why do we need a "virtual" DOM when the browser already gives us a real one?

In this article, we will see how virtual DOM works under the hood.

**The Core Problem**: Why react doesn't use real DOM

The DOM (Document Object Model) is a tree-like structure the browser uses to show your web page. when we modify JS object its fast, but modifying a Real DOM node is expensive, because the browser has to do a lot of heavy computing every time the Real DOM changes. It triggers a chain reaction:

**Reflow**: The browser recalculates the layout, sizes, and mathematical positions of every element on the screen.

**Repaint**: The browser physically redraws the pixels.

Doing this for every single small change in a dynamic, data-heavy web application leads to bad user experience.

**The Solution**: Virtual DOM to the rescue.

Virtual DOM is like a digital blueprint. It is a lightweight, purely JavaScript representation of the Real DOM. It has all the same properties (tags, classes, attributes), but it entirely lacks the physical weight of the browser's layout engine.

As it’s just a standard JavaScript object living in your computer's memory, React can create, delete, and update thousands of Virtual DOM nodes in a fraction of a millisecond without triggering a single screen repaint.

**The React Update Lifecycle**: Let's see step by step how its done

1.  **The Initial Render** When your React application first loads, the screen is empty. React calls your components, evaluates your JSX, and builds the very first Virtual DOM tree. Once the blueprint is complete, React translates it into Real DOM nodes and paints the screen.  
      
    `Initial Render Component (JSX) ➔ Virtual DOM Tree (Memory) ➔ Real DOM (Screen Painted)`
    

2.  **The Trigger** (State or Props Change): We are able to see the UI now. Let's say a user clicks a button that triggers a setState or useState hook.  
    React intercepts this state change. It knows that because the underlying data has changed, the UI might need to change. This is the trigger that queues a re-render.
    
3.  **Creating the New Virtual DOM Tree :** React runs your component functions again with the new state data and generates a new Virtual DOM tree  
      
    Now React have two blueprints in memory(say 2 different objects):
    
    The Old Virtual DOM (what is currently displayed on the screen).
    
    The New Virtual DOM (what the screen should look like now based on the new data).
    

4.  **Diffing and Reconciliation**: In this react knows what to show us new UI. It figure out what changed between the two virtual DOMs. This overarching process is called Reconciliation, and the algorithm used to compare the two trees is called Diffing. React compares the Old Tree to the New Tree, node by node.  
    Old Virtual Tree:  
    `<div> <h1>Dashboard</h1>`  
    `<p>Count: 0</p>`  
    `</div>`  
    New Virtual Tree:  
    `<div> <h1>Dashboard</h1>`  
    `<p>Count: 1</p> 👈 React knows this is changed`  
    `</div>`  
      
    React's algorithm is smart enough to find the **minimal required changes**. It sees that the `<div>` and the `<h1>` are completely identical, so it safely ignores them. It flags *only* the text inside the `<p>` tag as modified.
    
5.  **The Commit Phase** (Updating the Real DOM) Once React has a list of the minimal necessary changes (patch), it finally reaches out to the Real DOM.
    

It updates only the nodes that changed. The rest of the Real DOM is left completely untouched.  
  
`Patch Instruction: Update`  
`<p> textContent to "1" ➔ Applied to Real DOM`

**How and Why It Improves Performance** Creating a whole new Virtual DOM tree every time state, shouldn't it take more time?

Actually, no. Creating JavaScript objects in modern browser engines (like V8) is fast. The real performance drain has always been communicating with the browser's rendering engine.

The Virtual DOM improves performance through two main mechanisms:

*   **Surgical Precision**: By doing the "diffing" math in memory first, React completely avoids touching DOM nodes that haven't changed.
    
*   **Batching Updates**: If you trigger multiple state updates in a short window, React will batch them together in the Virtual DOM, calculate the final resulting difference once, and apply a single, consolidated update to the Real DOM.
    

**Summary**: To wrap up, whenever you build in React, keep this high-level lifecycle in your head:

1.  **Trigger**: A state or prop changes.
    
2.  **Render**: React creates a new Virtual DOM tree.
    
3.  **Diff**: React compares the new tree with the old tree (Reconciliation) to find the absolute minimum changes.
    
4.  **Commit**: React patches only those exact changes into the browser's Real DOM.
    

By understanding this flow, we now know virtual DOM and Ui updates works in React. React's Virtual DOM handles the heavy lifting of UI optimization, allowing us to focus on what really matters.