DEV Community: Shafiq Ur Rehman

How React Achieves High Performance, Even With Extra Layers

Shafiq Ur Rehman — Sun, 21 Sep 2025 14:10:41 +0000

A common interview question around React is:
“If DOM updates are already costly, and React adds Virtual DOM + Reconciliation as extra steps, how can it be faster?”

Many developers, including myself at one point, confidently answer: “Because of Virtual DOM!”
But that’s not the full picture. Let’s break it down properly.

First: How Browser Rendering Works (Brief Overview)

Before we talk about React’s optimizations, let’s first understand how the browser renders things by default.

When the browser receives HTML and CSS from the server, it:

Creates the DOM tree and CSSOM tree
Combines them into the Render Tree
Decides the layout, which element goes where
Finally, paints the pixels on screen

When something changes, like text content or styles, the DOM and CSSOM are rebuilt, the Render Tree is recreated, and then comes the expensive part: Reflow and Repaint.

In this process:

Positions are recalculated
Elements are repainted wherever styles or content have changed

Both Reflow and Repaint are costly operations, and this is exactly where React tries to help.

Now, let’s move to React and the Virtual DOM.

What Is Virtual DOM?

Virtual DOM is a lightweight copy of the actual DOM, represented as a JavaScript object.

Why was it needed? What was the problem with direct DOM manipulation?

Let’s look at an example.

// Normal DOM manipulation, NOT React
setInterval(() => {
  const span = document.createElement('span');
  span.textContent = new Date().toLocaleTimeString();
  document.getElementById('root').appendChild(span);
}, 1000);

Here, only the span’s time is updating. But if you inspect in DevTools, you’ll see the entire div re-rendering.

Modern browsers are smart; if other elements existed, they wouldn’t repaint them. But even then, in this case, the browser isn’t precise enough. The entire element container is being marked for update.

Now look at the same code in React:

function App() {
  const [time, setTime] = useState(new Date().toLocaleTimeString());

  useEffect(() => {
    const interval = setInterval(() => {
      setTime(new Date().toLocaleTimeString());
    }, 1000);
    return () => clearInterval(interval);
  }, []);

  return (
    <div>
      <h3>Current Time:</h3>
      <span>{time}</span>
    </div>
  );
}

Here, only the span updates. The div doesn’t re-render. React has already optimized the process at this level.

So how does React do this?

React creates a Virtual DOM.

First, it creates the initial Virtual DOM, a JS object tree mirroring your UI.

Example:

div
├── h3
├── form
│   └── input
└── span → "10:30 AM"

When state updates, say, time changes to “10:31 AM,” React creates a new Virtual DOM tree:

div
├── h3
├── form
│   └── input
└── span → "10:31 AM"

Then React compares the old and new Virtual DOM trees. This comparison process is called Diffing.

React sees: “Only the text inside span changed.” So it updates only that span in the Real DOM, and triggers repaint for just that node.

This comparison algorithm is called the Diffing Algorithm.

Two Key Optimizations in Diffing

Batching Updates

If multiple state updates happen, React doesn’t go update the DOM each time. It batches them together and applies them in one go.

Example:

setCount(1);
setName("Alice");
setLoading(true);

React will wait, collect all three, compute a final Virtual DOM, diff it, and update the Real DOM once.

This avoids multiple reflows/repaints.

Element Type Comparison Let’s say you have a login/logout UI:

function App({ isLoggedIn }) {
  if (isLoggedIn) {
    return <h1>Welcome back, user!</h1>;
  } else {
    return <button>Log In</button>;
  }
}

Initial Virtual DOM (logged out):

div → class="app"
└── button → "Log In"

Updated Virtual DOM (logged in):

div → class="app"
└── h1 → "Welcome back, user!"

React starts comparing from the root.

div → same → check props → class="app" → same → move on
Now children: button vs h1 → TYPE MISMATCH

React doesn’t try to “update” the button into an h1. It destroys the entire subtree and recreates it from scratch.

This is efficient because trying to morph one element into another is more expensive than just replacing it.

So far, this process seems optimized. Then why did React introduce Fiber?

Why Was Fiber Needed?

The original Reconciliation process had a critical flaw: It was synchronous and recursive.

Once started, it would run to completion, blocking the main thread.

Imagine this scenario:

User is typing in an input field
Meanwhile, 10 API calls return and trigger UI updates

Because React’s diffing was synchronous, it would process all 10 updates in one blocking pass, freezing the UI while the user is typing.

React had no way to say: “This user input is high priority, do it first. Those API updates? Do them later.”

Everything was treated equally and executed in one uninterrupted stack.

This hurt user experience.

So in React 16, Fiber was introduced.

What Is React Fiber?

React Fiber is a new Reconciliation algorithm. All updates in modern React go through Fiber.

Fiber solved the core problem: It made Reconciliation interruptible, prioritizable, and asynchronous.

Let’s understand how.

Fiber Working, Step by Step

Consider this component:

function App() {
  const [name, setName] = useState("");
  const [loading, setLoading] = useState(false);

  return (
    <div className="app">
      <h2 onClick={() => {
        setName("Shafique");
        startTransition(() => {
          setLoading(true);
        });
      }}>
        Click to Update
      </h2>
      <Profile name={name} />
      <Dashboard loading={loading} />
    </div>
  );
}

Here:

setName("Shafique") → high priority update (Sync Lane)
setLoading(true) wrapped in startTransition → low priority (Transition Lane)

Fiber will handle them differently.

Fiber Architecture, Key Concepts

1. Fiber Node

Every element, component, DOM node, and text becomes a Fiber Node.

Example component tree:

<App>
  ├── <h2>
  ├── <Profile>
  └── <Dashboard>

Becomes a Fiber Tree where each node is a unit of work.

2. Current Tree vs WIP(Work-In-Progress Tree)

Current Tree → The tree currently rendered on screen
Work-In-Progress (WIP) Tree → The tree being prepared for next render

When updates happen, React builds the WIP tree and then swaps it with the Current Tree during the Commit Phase.

Fiber Reconciliation Two Phases

Phase 1: Render Phase (Interruptible)

This phase has two sub-phases:

a. Begin Work

React visits each Fiber Node starting from the root.

It checks:

Does this node need update?
What’s the new state/props?
Create/clone Fiber Node for WIP tree

b. Complete Work

After a node’s children are processed, React:

Creates the actual DOM node (if new)
Links it to the Fiber Node via stateNode
Adds the Fiber Node to the “Effect List” if it needs a DOM update

Example:

fiber.stateNode = document.createElement('h2');

The Effect List is a linked list of nodes that need DOM mutations.

Traversal Order, Depth First

Fiber doesn’t use recursion; it uses a linked list with pointers:

child → first child
sibling → next sibling
return → parent

Traversal order:

Start at Root
Go to the child
Keep going to the child until the leaf
At leaf → go to sibling
If no sibling → go back to parent
Parents’ sibling? Go there. Otherwise, go to the grandparent.

Example:

Root
└── App
    ├── h2
    ├── Profile
    └── Dashboard

Traversal:

Root → App → h2 (leaf) → Profile (sibling) → Dashboard (sibling) → App (parent) → Root

At each node, Begin Work → then, after children → Complete Work.

Phase 2: Commit Phase (Synchronous)

Once the Render Phase is done, React has:

A complete WIP Fiber Tree
An Effect List with all nodes needing DOM updates

Now, React enters the Commit Phase, which is synchronous and uninterruptible.

It walks the Effect List and performs:

Insertions
Updates
Deletions

On the Real DOM.

Then, it swaps WIP Tree → becomes new Current Tree.

Update Phase, How Priorities Work

When state updates:

React creates an Update Object → { payload, timestamp, lane }
Enqueues it in the component’s update queue
Marks the Fiber Node (and all ancestors) as “needing work”
Schedules the update based on lane (priority)

Example:

// High priority
setName("Shafique"); // Sync Lane

// Low priority
startTransition(() => {
  setLoading(true); // Transition Lane
});

React’s Scheduler:

Checks which updates are pending
Assigns priority: Sync, Transition, Idle
Executes high-priority first

So when you click the button:

React creates a WIP(work-in-progress) tree
Processes setName("Shafique") → updates Profile
Skips setLoading(true) for now (low priority)
Commits → UI updates immediately
Later — starts new WIP tree → processes setLoading(true) → commits Dashboard update

The user sees instant feedback, and background work occurs later.

Fiber’s Real Power

Work is split into chunks → doesn’t block the main thread
High-priority work (user input) jumps the queue
Low priority work (data loading) waits — but doesn’t block
Browser gets breathing room → stays responsive

Even though Fiber adds more steps, it makes the right steps happen at the right time.

How Node.js Achieves High Performance & Scalability

Shafiq Ur Rehman — Sat, 20 Sep 2025 06:25:36 +0000

What is Node.js?

Node.js is an open-source JavaScript runtime environment that allows you to develop scalable web applications (accessible on the internet, without requiring installation on the user's device). This environment is built on top of Google Chrome’s JavaScript Engine V8. It uses an event-driven(waits for things to happen and then reacts to them), non-blocking I/O model(sends I/O requests and continuously does other work, notified when done), making it lightweight, more efficient, and perfect for data-intensive real-time applications running across shared devices.

Non-Blocking I/O: The Performance Game-Changer

Runs on the side stack (callback queue/microtask queue).
The main thread does not wait, async operations run in the background, and their callbacks execute later.
Example:

const fs = require('fs');
fs.readFile('file.txt', (err, data) => {     // Non-blocking
console.log(”This runs after the file reading is completes” , data);
});
console.log("This runs immediately");

 Here, console.log("This runs immediately") executes first, and the file reading happens in the background.

Node.js Architecture Overview

This architecture is mainly based on 5 key components:

1️⃣ Single Thread

2️⃣ Event Loop

3️⃣ Event Queue

4️⃣ Worker Pool (Libuv)

5️⃣ V8 Engine

Single Thread
Node.js operates in a single-threaded environment. This means:

Only one thread executes JavaScript code.

This thread handles the main event loop.

This is why Node.js is lightweight.

In simple terms, a single thread handles requests from multiple users, resulting in low memory usage.

The Event Loop: Node.js’s Secret Weapon
The event loop runs indefinitely and connects the call stack, the microtask queue, and the callback queue. The event loop moves asynchronous tasks from the microtask queue and the callback queue to the call stack whenever the call stack is empty.

Callback Queue:
Callback functions for operations like setTimeout() are added here before moving to the call stack.

Microtask Queue:
Callback functions for Promises and MutationObserver are queued here and have higher priority.

Event Queue
When asynchronous operations (like HTTP requests, database queries) are performed:

Node.js places them in the event queue.

The event loop then processes this queue when the main thread is free.

Offloading Heavy Work: Libuv & Worker Pool
Node.js is single-threaded, but that doesn’t mean it can’t do parallel work.

For blocking I/O tasks (file system, DNS, crypto, compression), Node.js uses Libuv’s Worker Pool, a pool of 4 background threads (configurable) that handle heavy lifting.

Why This Matters for Performance: Your main thread stays free to handle new requests. I/O-bound tasks run in parallel without blocking JavaScript execution. CPU-bound tasks? Use worker_threads or offload to microservices.

In simple terms, Node.js's single thread handles the main application logic, while heavy tasks are handled in the background by the worker pool.

V8 Engine: Raw Speed Under the Hood
Node.js runs on Google’s V8 JavaScript Engine, the same engine that powers Chrome.

Performance Benefits: Just-In-Time Compilation: Converts JS to optimized machine code at runtime. Dynamic Optimization: Frequently used functions get turbocharged. Garbage Collection: Efficient memory management prevents leaks and slowdowns. V8 is why Node.js apps start fast, run fast, and stay fast, even under heavy load.

Node.js Flow Example:

1️⃣ A user sends an API request.

2️⃣ Node.js receives the request.

3️⃣ If the request involves:

A non-heavy CPU task is executed directly via the event loop.

A heavy task (like reading a file) is sent to the worker pool.

4️⃣ While the task is processing, the event loop continues to handle other requests.

5️⃣ Once the task is complete, its callback function is placed in the event queue.

6️⃣ The event loop picks up the callback and executes it.

7️⃣ Node.js sends the response back to the user.

Pro Tips for Optimizing Node.js Performance

Never Use Sync APIs
→ readFileSync and writeFileSync will destroy your server's throughput.

Use Async/Await or Promises
→ Less messy, faster, and easier to debug than callbacks.

Cluster Your App
→ Utilize all CPU cores using the cluster module.

Offload CPU Work
→ Leverage worker_threads for heavy computation.

Use Caching & Streaming
→ Minimize I/O roundtrips. Stream large files instead of loading into memory.

Final Thought

Node.js doesn’t achieve high performance by throwing more hardware at the problem; it does so by being intelligent with resources. Its event-driven, non-blocking model is purpose-built for modern, I/O-heavy applications.

Master these concepts, avoid blocking code, and you’ll unlock Node.js’s true potential: a server that’s fast, lean, and ready to scale

JavaScript Execution Context Made Simple

Shafiq Ur Rehman — Thu, 21 Aug 2025 10:19:34 +0000

A JavaScript engine is a program that converts JavaScript code into a Binary Language. Computers understand the Binary Language. Every web browser contains a JavaScript engine. For example, V8 is the JavaScript engine in Google Chrome.

Let's dive in!

Execution context: Execution Context is the environment in which JS code runs. It decides what variables and functions are accessible, and how the code executes. It has two types (Global & Function) and works in two phases (Memory Creation & Code Execution).

1. Global Execution Context (GEC)

This is created once when your script starts. It's the outermost context where:

Global variables and functions are stored
this refers to the global object (like window in browsers)

2. Function Execution Context (FEC)

When you call a function, a new context is created specifically for that function. It manages:

The function's local variables
The value of this inside the function
Arguments passed to the function

3. Memory Creation Phase

This is the first phase of an execution context. During this phase:

All variables and functions are allocated in memory
Functions are fully hoisted (stored with their complete code)
Variables declared with var are hoisted and initialized with undefined
Variables declared with let and const are also hoisted but remain uninitialized, staying in the Temporal Dead Zone (TDZ) until their declaration is reached

4. Code Execution Phase

This is the second phase, where:

The code executes line by line
Variables receive their actual values
Functions are called when invoked

The Variable Environment is a part of the Execution Context.
It is where all variables, functions, and arguments are stored in memory as key-value pairs during the Memory Creation Phase.

It includes:
- Variable declarations
- Function declarations
- Function parameters
It is used internally by the JS engine to track what's defined in the current scope.
Call stack: The call stack is a part of the JavaScript engine that helps keep track of function calls. When a function is invoked, it is pushed to the call stack, where its execution begins. When the execution is complete, the function is popped off the call stack. It utilizes the concept of stacks in data structures, following the Last-In-First-Out (LIFO) principle.
Event loop: The event loop runs indefinitely and connects the call stack, the microtask queue, and the callback queue. The event loop moves asynchronous tasks from the microtask queue and the callback queue to the call stack whenever the call stack is empty.
In JavaScript’s event loop, microtasks always have higher priority than macrotasks (callback queue).
Callback Queue (Macrotask Queue): Callback functions for setTimeout() are added to the callback queue before they are moved to the call stack for execution.

Includes:

setTimeout()
setInterval()
setImmediate()
I/O events
Microtask queue: Asynchronous callback functions for promises and mutation observers are queued in the microtask queue before they are moved to the call stack for execution.
Includes things like:
- Promise.then()
- Promise.catch()
- Promise.finally()
- MutationObserver

Synchronous JavaScript

JavaScript is synchronous, blocking, and single-threaded. This means the JavaScript engine executes code sequentially—one line at a time from top to bottom—in the exact order of the statements.

Consider a scenario with three console.log statements.

console.log("First line");
console.log("Second line");
console.log("Third line");

Output:
First line
Second line
Third line

Let's examine another example:

function getName(name) {
  return name;
}

function greetUser() {
  const userName = getName("Shafiq Ur Rehman");
  console.log(`Hello, ${userName}!`);
}

greetUser();

A new global execution context is created and pushed onto the call stack. This is the main execution context where the top-level code runs. Every program has only one global execution context, and it always stays at the bottom of the call stack.
In the global execution context, the memory creation phase starts. In this phase, all variables and functions declared in the program are allocated space in memory (called the variable environment). Since we don’t have variables declared in the global scope, only the functions will be stored in memory.
The function getName is stored in memory, with its reference pointing to the full function body. The code inside it isn’t executed yet—it will run only when the function is called.
Similarly, the function greetUser is stored in memory, with its reference pointing to its entire function body.
When the greetUser function is invoked, the code execution phase of the global execution context begins. A new execution context for greetUser is created and pushed on top of the call stack. Just like any execution context, it first goes through the memory allocation phase.
Inside greetUser, the variable userName is allocated space in memory and initialized with undefined. (Note: During memory creation, variables declared with var are initialized with undefined, while variables declared with let and const are set as uninitialized, which leads to a reference error if accessed before assignment.)
After the memory phase finishes, the code execution phase starts. The variable userName needs the result of the getName function call. So getName is invoked, and a new execution context for getName is pushed onto the call stack.
The function getName allocates space for its parameter name, initializes it with undefined, and then assigns it the value "Shafiq Ur Rehman". Once the return statement runs, that value is returned to the greetUser context. The getName execution context is then popped off the call stack. Execution goes back to greetUser, where the returned value is assigned to userName. Next, the console.log statement runs and prints:
```
Hello, Shafiq Ur Rehman!
```
Once done, the greetUser The execution context is also popped off the call stack.
Finally, the program returns to the global execution context. Since there’s no more code left to run, the global context is popped off the call stack, and the program ends.

Asynchronous JavaScript

Unlike synchronous operations, asynchronous operations don't block subsequent tasks from starting, even if the current task isn't finished. The JavaScript engine works with Web APIs (like setTimeout, setInterval, etc.) in the browser to enable asynchronous behavior.

Using Web APIs, JavaScript offloads time-consuming tasks to the browser while continuing to execute synchronous operations. This asynchronous approach allows tasks that take time (like database access or file operations) to run in the background without blocking the execution of subsequent code.

Let’s break this down with a setTimeout() example. (I’ll skip memory allocation here since we already covered it earlier.)

console.log("first");

setTimeout(() => {
  console.log("second");
}, 3000);

console.log("third");

Here’s what happens when this code runs:

The program starts with a global execution context created and pushed onto the call stack.
The first line console.log("first") runs. It creates an execution context, prints "first" to the console, and then is popped off the stack.
Next, the setTimeout() function is called. Since it’s a Web API provided by the browser, it doesn’t run fully inside the call stack. Instead, it takes two arguments: a callback function and a delay (3000ms here). The browser registers the callback function in the Web API environment, starts a timer for 3 seconds, and then setTimeout() itself is popped off the stack.
Execution moves on to console.log("third"). This prints "third" immediately, and that context is also popped off.
Meanwhile, the callback function from setTimeout is sitting in the Web API environment, waiting for the 3-second timer to finish.
Once the timer completes, the callback doesn’t go straight to the call stack. Instead, it’s placed into the callback queue. This queue only runs when the call stack is completely clear. So even if you had thousands of lines of synchronous code after setTimeout, they would all finish first.
The event loop is the mechanism that keeps watching the call stack and the queues. When the call stack is empty, the event loop takes the callback from the queue and pushes it onto the stack.
Finally, the callback runs: console.log("second") prints "second" to the console. After that, the callback function itself is popped off, and eventually, the global execution context is cleared once everything has finished.

Conclusion

JavaScript runs code synchronously but can handle async tasks using browser Web APIs. Knowing how the engine works under the hood is key to mastering the language.

“Let me know your thoughts in the comments,” or “Follow me for more JavaScript insights.”