Forem: Naga Rohith

Inside Node.js: A Deep Dive into V8, libuv, the Event Loop & Thread Pool

Naga Rohith — Wed, 19 Nov 2025 21:27:24 +0000

Hey there! If you've ever used Node.js, you've probably heard the terms "non-blocking I/O," "single-threaded," or "event loop." We often use Node.js as a black box we put JavaScript in, and performance comes out. But what's really happening under the hood?

What is the event loop? How can Node be "single-threaded" but handle thousands of connections? What's V8, and how is it different from libuv?

If you're a developer looking to truly master Node.js, or just a curious mind who wants to peek behind the curtain, this guide is for you. We're not just scratching the surface. We're diving deep into Node.js internal working.

This is the ultimate guide to Node.js internals. Let's get started.

The V8 Engine

The V8 engine is the high-performance JavaScript and WebAssembly engine created by Google and used by both Chrome and Node.js. At its core, V8 is responsible for taking JavaScript source code, parsing it, converting it into an internal representation, and ultimately compiling it into highly optimized machine code that runs directly on the CPU. Unlike older JavaScript engines that relied heavily on slow interpreters, V8 uses a modern architecture consisting of a parser, an interpreter called Ignition, and an advanced optimizing compiler called TurboFan, which work together to provide fast startup times and aggressive runtime optimizations.

It manages memory through a generational garbage collector, uses hidden classes and inline caching to speed up property lookups, and applies several optimization heuristics at runtime based on how your code behaves. Understanding how V8 compiles, optimizes, and executes JavaScript is fundamental to understanding Node.js performance, because almost everything that happens in a Node application including closures, async callbacks, microtasks, event loop execution, and memory allocation ultimately runs inside the V8 execution environment.

Ignition Interpreter & TurboFan Compiler

In the old days, JavaScript was purely interpreted, which was slow. Then, compilers came along, which were faster but had a high startup cost. V8 uses a hybrid approach.

Ignition Interpreter
When your code first runs, it's fed to the Ignition interpreter. Ignition's job is to execute the code line-by-line as quickly as possible. This turns the code into bytecode an intermediate, lower-level language closer to machine instructions but still flexible for quick startup. It doesn't waste time on optimization. While it's running, Ignition also gathers profiling data like which functions are called often, or which types of variables are used.This means your app starts fast, without waiting for all code to be compiled.
TurboFan Optimizing Compiler
When Ignition flags a piece of code as "hot" (e.g., a function that's been run 1000 times or When it spots pieces getting a lot of action think loops or hot functions), it passes that code and the profiling data to TurboFan. TurboFan is an optimizing compiler. It takes its time, looks at the profiling data, and makes smart assumptions to generate hyper-optimized machine code delivering the best of both worlds: immediate startup and high performance over time.

Hidden Classes

JavaScript objects look simple on the surface just key-value pairs. But underneath, V8 uses a concept called hidden classes (sometimes called "maps" or "shapes") to optimize property access speed.
When you create an object in JavaScript, like:

const user = {};
user.name = "Alice";
user.age = 30;

V8 doesn’t just store properties randomly. Instead, it creates a hidden class that acts as an internal blueprint describing the layout of the object’s properties in memory. Step-by-step:

When you do const user = {}, V8 creates an initial hidden class (say C0) with no properties.
When you add user.name = "Alice", it creates a new hidden class C1 that extends C0 by adding a property named name at a specific memory offset.
When you add user.age = 30, it creates hidden class C2, with both name and age properties, each at fixed offsets.

Creating another object with the same property additions in the same order causes V8 to reuse the existing hidden classes, enabling fast, predictable property lookups based on known memory layouts.

Inline Caching

Caching is the process of storing the result of an expensive operation (like a database query or complex calculation) so that future requests for that same data can be served instantly without repeating the work.

Inline Caching is a specific optimization technique where the engine stores the result of a property lookup directly within the compiled machine code at the "call site" (the specific line where the function is called), eliminating the need to look up where a property lives in memory every time.

V8 Uses It Inline Caching acts as a turbocharger for Hidden Classes. When V8 accesses a property for the first time, it calculates the memory location and "patches" the code with a shortcut (a stub) pointing directly to that memory offset. If subsequent objects share the same Hidden Class (monomorphic), V8 uses this shortcut to skip the lookup entirely, achieving near-native speeds. However, if the object shapes constantly change (polymorphic), V8 is forced to abandon these optimized stubs and revert to slower, generic lookup methods.

Memory Layout

V8 manages memory by dividing it primarily into two areas: the stack and the heap, with the heap further subdivided for optimal garbage collection.

The stack is a small, managed memory region where V8 stores static data such as function call frames, primitive values and pointers to objects on the heap. This memory is tightly managed by the operating system and follows a Last-In-First-Out (LIFO) pattern, making it very fast for local variable access and function calls.

The heap, on the other hand, is where dynamic data lives this is where all JavaScript objects, arrays, functions, and closures are allocated. Because JavaScript is dynamic and objects can change shape and size at runtime, the heap must be flexible and efficiently managed by the garbage collector to avoid memory leaks and fragmentation.

Inside the heap, V8 implements a generational memory model by dividing it into:

New Space (Young Generation): This is a smaller area dedicated to newly created objects. Most of these objects are short-lived, such as temporary variables or intermediate results. Because many objects become unreachable quickly, V8 runs a fast, frequent garbage collection (called minor GC) here to reclaim memory efficiently.
Old Space (Old Generation): Objects that survive several minor garbage collections in the new space are promoted to the old space. This area holds longer-lived objects like caches, application data structures, or closures persisting across many function calls. Garbage collection in old space is more comprehensive but less frequent, involving techniques like mark-sweep and mark-compact to optimize memory usage over time.

This separation allows V8 to optimize around common JavaScript object lifecycles: quick cleanup of transient objects in new space and thorough maintenance of persistent objects in old space, ensuring better performance and minimal interruption during program execution.

2. Node.js Architecture: More Than Just V8

Node.js is not V8. Node.js is a runtime that uses V8.

Node.js is designed for building scalable network applications by leveraging a lightweight, event-driven architecture. As it runs on the V8 JavaScript engine, which compiles JavaScript code into fast machine code, enabling efficient execution on the server side.

The Single-Threaded Event Loop

Unlike traditional multi-threaded servers that spawn multiple threads per request, Node.js operates on a single main thread known as the event loop. This event loop continuously monitors an event queue where asynchronous events, such as incoming HTTP requests, timers, or I/O completions—are placed.

Because the event loop handles tasks one at a time and delegates blocking tasks to background threads, Node.js efficiently manages thousands of concurrent connections with low overhead.

libuv and Thread Pool for Async I/O

To handle blocking operations like file system access or database calls without blocking the event loop, Node.js uses libuv, a C library that provides an abstraction for asynchronous I/O.

Libuv maintains a thread pool (default size 4) that executes heavy, blocking operations in parallel. When these operations complete, their callbacks are queued back on the event loop, allowing your JavaScript code to continue processing.

This design keeps the main thread free and responsive, achieving non-blocking concurrency in a single-threaded execution environment.

Event-Driven Programming Model

Node.js popularized the event-driven style of programming, where events emitted by the system or users trigger asynchronously executed callback functions. Core Node modules and frameworks like Express.js make extensive use of this pattern to build real-time features such as websockets, APIs, and streaming data applications.

3. Understanding the Node.Js Event Loop

The event loop is the core mechanism that enables Node.js to handle asynchronous operations on a single thread. Instead of blocking the main thread waiting for operations to complete (like I/O), Node.js uses the event loop to schedule callbacks and manage concurrency efficiently.

Node.js has an event queue where callbacks from asynchronous operations are placed. The event loop continuously checks this queue and processes callbacks one by one, making Node.js non-blocking.

Here's a simple example demonstrating how asynchronous callbacks enter the event loop:

console.log('Start');

setTimeout(() => {
  console.log('Timeout callback');
}, 0);

console.log('End');

Output:
Start End Timeout callback
Even with a timeout of 0, the callback runs after the synchronous code because it waits for the event loop to pick it up.

The Six Phases of the Event Loop

The event loop executes in a cycle consisiting of six distinct phases:

Timers
Executes callbacks scheduled by setTimeout() and setInterval() whose timer thresholds have elapsed.
Pending Callbacks
Executes I/O callbacks deferred to the next loop iteration, such as some TCP errors.
Idle, Prepare
Internal operations for Node.js—used to prepare the event loop.
Poll
It retrieves new I/O events (like a network request completing).
It executes the callbacks for those I/O events (like the (req, res) in an HTTP server).
If the loop has nothing else to do, it will block and "poll" the OS here, waiting for new events to arrive.
Check
Executes callbacks scheduled by setImmediate().
Close Callbacks
Executes callbacks for closed events like sockets or handles.

Macrotasks vs. Microtasks

This is where most people get confused. The 6 phases above handle Macrotasks. A setTimeout callback is a macrotask. A setImmediate callback is a macrotask. An I/O callback is a macrotask.

Microtasks are different. They live in their own queues and have higher priority. They are:

process.nextTick() callbacks
Promise callbacks (.then(), .catch(), .finally(), and await)

Here is the golden rule:

After every Macrotask, and before the Event Loop moves to the next phase, it will completely drain the Microtask queue.

Let's trace:

Event Loop enters the timers phase.
It finds one setTimeout callback (a Macrotask) and executes it.
STOP! Before moving to the pending callbacks phase, the loop checks the Microtask queue.
It finds 10 Promise .then() callbacks. It runs all 10.
The Microtask queue is now empty.
Now the loop moves on to the pending callbacks phase.

How Promises "Jump" Phases
This Microtask behavior is why promises can "jump" the line.

const fs = require('fs');

// Macrotask (Poll Phase)
fs.readFile('file.txt', () => {
  console.log('1. I/O');

  // Macrotask (Check Phase)
  setImmediate(() => console.log('2. Immediate'));

  // Microtask (Promise)
  Promise.resolve().then(() => console.log('3. Promise'));
});

// Macrotask (Timer Phase)
setTimeout(() => console.log('4. Timeout'), 0);

Output:
`4. Timeout

I/O
Promise
Immediate`

Why?

The setTimeout (timer) and fs.readFile (I/O) are initiated.
The loop hits the timers phase. It finds the setTimeout callback and executes it. 4. Timeout is logged.
The loop moves through pending, idle, and into the poll phase.
It finds the completed fs.readFile callback (a Macrotask). It executes it. 1. I/O is logged.
Inside that callback, a setImmediate (Macrotask for check phase) and a Promise.resolve (Microtask) are queued.
STOP! The fs.readFile macrotask is done. The loop must drain the microtask queue before moving to the check phase.
It finds the promise callback and executes it. 3. Promise is logged.
The microtask queue is empty.
The loop moves to the check phase. It finds the setImmediate callback and executes it. 2. Immediate is logged.

Avoiding Event Loop Starvation:

Heavy use of microtasks (e.g., using too many process.nextTick() calls) can starve the event loop, preventing it from moving to the I/O phases. This blocks I/O and timers from executing, causing application delays.

The event loop orchestrates the asynchronous behavior that powers Node.js's concurrency under the hood. Understanding its phases, microtask vs macrotask queues, and nuances like setImmediate() helps build highly performant and scalable applications.

4. libuv Internals

So, libuv gives us the Event Loop. But how does it actually handle I/O? How does it wait for 10,000 network connections at once without blocking?

Event Demultiplexer

This is the core. Libuv doesn't check every socket one by one. That would be slow (this is "select"). Instead, it uses the most efficient mechanism available on the host OS:

epoll on Linux
kqueue on macOS and BSD
IOCP (I/O Completion Ports) on Windows

It gives the OS kernel a list of all the sockets and files it cares about and says, "Hey, I'm going to sleep. Wake me up only when one of these has data to read, is ready to write, or has an error."

This Event Demultiplexer is a single C function call (like epoll_wait) that efficiently waits for any event to happen. When it returns, it gives libuv a list of only the events that are ready. This is why Node can handle immense I/O concurrency with a single thread.

Handles & Requests

Inside libuv, everything is one of two things:

Handles: These represent long-lived objects that can perform operations. A TCP server (net.Server) is a handle. A timer (setTimeout) is a handle.
Requests: These represent short-lived, one-off operations. A fs.readFile operation is a request. A dns.lookup is a request.

When you call fs.readFile, Node's C++ bindings create a fs_req (request) object, give it your callback, and hand it to libuv.

Queues
Libuv maintains all the queues for the Event Loop phases. When the Event Demultiplexer says, "Socket 5 has data," libuv finds the handle for Socket 5, executes its C-level read operation, and then queues the JavaScript callback (with the data) to be run in the poll phase.

The Thread Pool: Handling the Heavy Lifting

Your JavaScript code and the Event Loop run on a single main thread. But Node.js itself (and libuv) is not single-threaded.

Libuv maintains a Thread Pool (by default, 4 threads) to handle operations that are unavoidably blocking or CPU-intensive.

Why 4 Threads?

It's just a default. It was a good "guess" that works for most 4-core CPUs. You can change this by setting the UV_THREADPOOL_SIZE environment variable before your Node process starts.

UV_THREADPOOL_SIZE=8 node my_app.js

Which Operations Use the Thread Pool?

This is a critical distinction.

Network I/O does NOT use the thread pool. Modern OS-level APIs (epoll, kqueue) are already non-blocking. Libuv handles network I/O on the main thread via the Event Demultiplexer.
Blocking I/O and CPU-Bound tasks DO use the thread pool. This includes:
All fs module operations (e.g., fs.readFile, fs.stat) because file system access is (on most platforms) a blocking OS call.
Most crypto functions (e.g., crypto.pbkdf2, crypto.randomBytes) because they are very CPU-intensive.
dns.lookup (but not dns.resolve, which is network-based).
zlib for compression/decompression.

Performance Considerations

Imagine you have a 4-core server (default 4 threads) and you get 5 requests at once to hash a password using crypto.pbkdf2.

The first 4 requests will be dispatched to the 4 threads in the pool.
The 5th request must wait for one of the first 4 to finish before it can even start.
While this is happening, any fs.readFile calls will also have to wait for a free thread.

This is a bottleneck. Your event loop might be free, but your thread pool is saturated. Increasing the pool size might help, but the real, modern solution for CPU-bound work is to use Worker Threads (which are separate Node.js runtimes, not from the libuv thread pool) to run your JS in parallel.

Worker threads:

These are separate JavaScript threads exposed explicitly via the Node.js worker_threads module. Unlike the libuv thread pool, worker threads allow running JavaScript code in parallel threads managed by the user. Each worker has its own event loop and memory space, communicating with the main thread via messaging.

Never block the event loop with heavy computation. Delegate it! Use the thread pool or proper worker threads. Always measure and tune thread pool size based on workload.

How Everything Works Together in Node.js

JavaScript Execution with V8 Engine
Your Node.js application code is executed by the V8 engine. V8 compiles JavaScript into fast machine code, enabling efficient synchronous execution on the main thread.
Single-Threaded Event Loop Orchestrates Concurrency
The main thread runs the event loop, which continuously polls the event queue for incoming asynchronous events and callbacks to execute one by one.
Delegation to libuv for Asynchronous I/O
When your code makes asynchronous calls like file system access, network requests, or timers, Node.js delegates these to libuv. libuv either registers these with the OS's native asynchronous APIs (epoll, kqueue, IOCP) or pushes blocking tasks to its internal thread pool.
libuv Thread Pool for Blocking Operations
For operations that cannot be performed asynchronously by the OS, libuv uses a configurable thread pool (default 4 threads) to run these tasks in parallel worker threads without blocking the main event loop.
Callback Queueing and Event Loop Processing
Once libuv completes I/O or blocking tasks, it queues the associated callbacks back onto the event loop’s event queue for execution on the main thread.
Worker Threads for Parallel JavaScript Execution
Separately, Node.js supports worker threads that run JavaScript code in parallel, each with their own event loops and memory. These are created explicitly via the worker_threads module for CPU-intensive or parallelizable workloads.
Event-Driven Architecture Enables Responsive Apps
Events emitted by the system or user trigger registered callbacks, facilitating non-blocking, reactive application design suited for real-time scenarios.

JS code  →  V8 (executes sync JS)
    ↓
Async API call
    ↓
libuv registers I/O or delegates to thread pool
    ↓
Blocking tasks → Worker threads (libuv pool)
    ↓
I/O or task completion signals libuv
    ↓
Callbacks queued in event loop
    ↓
Main thread runs callbacks via event loop

Each component seamlessly collaborates to maximize Node.js scalability and responsiveness, handling thousands of concurrent operations with minimal overhead.

Conclusion

Node.js combines the fast V8 engine, an efficient single-threaded event loop, and libuv’s async I/O with a thread pool to handle blocking tasks smoothly. Worker threads enable parallel JavaScript execution for CPU-heavy jobs. This architecture lets Node.js scale easily and stay responsive, making it ideal for real-time and I/O-intensive applications.

Understanding this helps developers write better-performing, scalable apps that fully leverage Node.js’s strengths.

If you found this helpful, don’t forget to like, comment, and follow to see more blogs. Let’s keep learning together. Happy Coding!

The Language Behind the Web: How JavaScript Works!

Naga Rohith — Wed, 22 Oct 2025 17:30:35 +0000

JavaScript is the language behind the web, powering almost everything you see and interact with online. But beyond the code we write, there’s a complex system at work, parsing, compiling, and executing every instruction with precision.

In this blog, we’ll explore how JavaScript truly works under the hood: how the engine runs your code, manages execution, handles asynchronous tasks, and cleans up memory. Understanding these internals will help you write smarter, more efficient code and see JavaScript from a whole new perspective.

Javascript Engine Overview

At its core, JavaScript is a single-threaded, interpreted (or just-in-time compiled) language that powers interactivity on the web.

Being single-threaded, JavaScript executes one task at a time in a single main thread. Yet, it can handle network requests, animations, and user interactions without freezing the page. This is possible because, while JavaScript itself is synchronous, it achieves asynchronous behavior through callbacks, promises, and the event loop.

Every time you run JavaScript, an engine called V8 in Chrome and Node.js, SpiderMonkey in Firefox, or JavaScriptCore in Safari, is at work. The engine parses, compiles, and executes your code in three main stages.

Parsing: The code is read and transformed into an Abstract Syntax Tree (AST), a structured representation of the program.
Compilation: Modern engines use Just-In-Time (JIT) compilation, combining interpretation with on-the-fly optimization for better performance.
Execution: The code runs inside an Execution Context, which is managed by the Call Stack.

This hybrid process ensures your code runs efficiently while enabling the synchronous engine to handle asynchronous tasks seamlessly.

Execution Context

When a JavaScript program runs, the engine first creates the Global Execution Context (GEC), the base environment where all code starts executing. There is only one GEC per program. It has two main phases:

-> Creation Phase

Allocates memory for variables and function declarations.
Defines the Global Object (window in browsers, global in Node.js).
Sets up this to reference the Global Object in the global scope.
Performs hoisting, which allocates space for variables and functions before execution begins.

-> Execution Phase

Executes code line by line.
Assigns values to variables.
Invokes functions, each of which creates its own Function Execution Context (FEC).

The Function Execution Context behaves similarly to the GEC but with a few key differences:

Each function call creates a new FEC.
Contains its own Variable Environment for local variables and parameters.
Has its own this value, determined by how the function is called.
Executes in two phases, creation and execution, just like the GEC.

Execution contexts are managed using the Call Stack, ensuring that the engine executes functions in the correct order. Once a function finishes, its FEC is removed from the stack, and control returns to the previous context.

In short: The Global Execution Context is the base environment for your program, while each Function Execution Context handles the execution of individual functions. Together, they provide the framework for how JavaScript organizes memory and executes code.

The Call Stack

Think of the Call Stack as your program’s to-do list. It keeps track of which functions are currently running and what needs to run next. Whenever a function is called, a new Function Execution Context (FEC) is created and pushed onto the stack. Once that function completes, its context is popped off, allowing JavaScript to return to the previous task in order.

Let's illustrate:

function one() {
  console.log('First');
  two();
}

function two() {
  console.log('Second');
}

one();
console.log('Third');

Here's what happens:

GEC is created and pushed to the stack.
one() is called → FEC for one() is created.
Inside one(), two() is called → FEC for two() is added.
two() finishes → popped off.
one() finishes → popped off.
Back to global → prints Third.

In short: The Call Stack manages the order of function execution. JavaScript runs one function at a time, always finishing the most recent one before returning to the previous, just like crossing items off a to-do list from the top down.

Hoisting and the Temporal Dead Zone (TDZ)

Hoisting is JavaScript’s process of allocating memory for variables and functions during the creation phase of the execution context, before any code runs. This gives the illusion that declarations are “moved” to the top of their scope (though only in memory, not physically in the code).

The Temporal Dead Zone (TDZ) is the period between hoisting and the actual initialization of let and const variables. During this phase, the variables exist in memory but are uninitialized and cannot be accessed. Any attempt to use them before their declaration line results in a ReferenceError, ensuring safer and more predictable code behavior.

how the hoisting and TDZ works:

-> Function Declarations:

Fully hoisted and initialized before execution starts.
Can be invoked anywhere in their scope, even before their definition in code.

-> Variable Declarations:

var variables are hoisted and initialized with undefined.
let and const are hoisted but remain uninitialized until their declaration line, the time between hoisting and initialization is called the Temporal Dead Zone (TDZ).
Accessing them in the TDZ results in a ReferenceError.

-> Function Expressions and Arrow Functions:

When defined using var, they behave like variables, hoisted and initialized as undefined, causing errors if called before declaration.
When defined with let or const, they’re also subject to the TDZ and cannot be accessed before initialization.

greet(); // Works — function declaration is hoisted
sayHello(); // TypeError — sayHello is undefined
console.log(num); // ReferenceError (TDZ)

function greet() {
  console.log("Hello!");
}

var sayHello = function () {
  console.log("Hi!");
};

let num = 10;

Explanation:

During the creation phase, the engine fully hoists greet() and stores it in memory.
sayHello, declared with var, is hoisted but set to undefined, calling it before initialization throws a TypeError.
num, declared with let, is hoisted but remains in the TDZ until its line of execution.

Key takeaways:

Function declarations take priority in hoisting.
Variables declared with var are initialized with undefined.
let, const, and function expressions are hoisted but uninitialized (TDZ applies).
Understanding these differences helps prevent subtle reference and type errors in your code.

Event Loop and Asynchronous Model

Despite being single-threaded, JavaScript handles asynchronous tasks efficiently using a mechanism involving the Event Loop, Web APIs, and task queues. This allows JavaScript to remain responsive while performing operations like network requests, timers, and DOM events.

The Event Loop is the engine that coordinates this process. It continuously monitors the Call Stack and the task queues. When the Call Stack is empty, the Event Loop moves tasks from the queues to the stack, ensuring that asynchronous callbacks execute in the correct order.

How it works:

-> The Call Stack runs all synchronous code first.
-> Web APIs handle asynchronous operations, such as setTimeout, fetch, DOM events, or async functions. These tasks are processed independently of the main thread.
-> Once an asynchronous operation is complete, its callback is placed in one of two queues:

Microtask Queue – for Promises, async/await, and MutationObserver callbacks.
Macrotask (Callback) Queue – for setTimeout, setInterval, I/O tasks, and UI events.

-> The Event Loop checks if the Call Stack is empty.

If empty, it first pulls all microtasks from the Microtask Queue to the Call Stack.
Only after the microtasks are completed, a task from the macrotask (callback) queue is pushed onto the stack.

-> This cycle repeats continuously, keeping the JavaScript engine responsive while handling asynchronous tasks efficiently.

Key points:

Microtasks have priority over macrotasks; they always execute first once the stack is empty.
Even a setTimeout with 0ms delay waits until all synchronous code and microtasks complete.
The Event Loop ensures JavaScript remains non-blocking despite being single-threaded.

Code:

console.log("Start");

setTimeout(() => {
  console.log("Macrotask: Timeout");
}, 0);

Promise.resolve().then(() => {
  console.log("Microtask: Promise");
});

console.log("End");

Output:

Start End Microtask: Promise Macrotask: Timeout

Memory Mnagement and Garbage Collection

JavaScript automatically handles memory. It keeps track of variables and objects, and frees memory when they are no longer needed.The memory is stored in as two parts:

1. stack:
The stack stores primitive values (numbers, strings, booleans) and references to functions. It works in a Last-In-First-Out (LIFO) manner, meaning values are pushed when functions are called and popped when they return. Stack memory is small, fast, and used for simple, short-lived data.

2. Heap:
The heap stores objects, arrays, and complex data structures. Unlike the stack, heap memory is unstructured and accessed via references. Objects in the heap remain as long as there is a reference to them, and they are larger and slower than stack memory.

Garbage Collection:
JavaScript automatically frees memory that is no longer reachable. The most common method is Mark-and-Sweep: the engine starts from roots (like global objects and the call stack), marks all reachable objects, and reclaims memory used by unreachable objects. This prevents memory leaks and ensures efficient memory usage.

Example:

let name = "Alice"; // stored in Stack
let user = { age: 25 }; // object stored in Heap, reference in Stack

function greet() {
  let message = "Hello"; // stored in Stack
  console.log(message);
}

greet();
user = null; // object in Heap becomes unreachable and eligible for GC

Explanation:
Primitives like nameare stored on the stack, while objects like userare in the heap with a reference in the stack. Setting user = null removes the reference, making the heap object unreachable and ready for garbage collection.

Engine Optimizations - Why Javascript is so fast

Modern engines like V8 have advanced optimizers that continuously monitor, recompile, and optimize code while it runs.

Here's how it works:

1. Hidden Classes
When you create an object, V8 dynamically assigns it a hidden class that defines its structure.
If you add properties consistently (in the same order), the engine can optimize access patterns dramatically.

function Person(name, age) {
  this.name = name;
  this.age = age;
}
const p1 = new Person('Alice', 25); // Fast

But if you later add new properties dynamically or in a different order, the engine deoptimizes the object, leading to slower property access.

2. Inline Caching
The engine remembers how functions are used and assumes similar patterns in future calls. This cached assumption boosts speed, as re-checking property lookups becomes unnecessary.

function greet(person) {
  return person.name;
}
greet({ name: 'Tom' });
greet({ name: 'Jerry' }); // Faster after inline cache warm-up

3. Hot Path Optimization
V8 detects “hot” (frequently executed) code and recompiles it into optimized machine code to make execution near-native fast. If assumptions break, it safely “deoptimizes” that section back to normal.

4. Constant Folding & Dead Code Elimination
During JIT compilation, V8 simplifies constant expressions (2 + 3 → 5) and removes unused code for efficiency.

5. Garbage Collection Enhancements
Modern engines use incremental and generational garbage collection, allowing smooth memory management without noticeable performance drops.

Wrapping It All Up

Let's recap the inner workings of javascript:

Engine reads and prepares code for execution.
Global Execution Context starts your program.
Hoisting pulls declarations up for organized execution.
Temporal Dead Zone (TDZ) ensures safe variable access.
Call Stack manages functions in sequence.
Heap stores dynamic data.
Event Loop orchestrates asynchronous behavior seamlessly.
JIT and Engine Optimizations keep performance lightning fast.

JavaScript might appear simple, but it runs on a sophisticated runtime that efficiently handles concurrency, memory, and performance optimizations. That’s why calling it “The Language Behind the Web” fits perfectly — every click, animation, and API call online flows through this system.

If you found this helpful, don’t forget to like, comment, and follow to see more blogs. Let’s keep learning together. Happy Coding!

The Complete Guide to React.js Internal Workings: From Code to Browser

Naga Rohith — Tue, 14 Oct 2025 08:08:37 +0000

React has revolutionized how we build user interfaces, but have you ever wondered what happens behind the scenes when you write React code?
This comprehensive guide will take you through every step of React's internal workings, from writing JSX to seeing the final result in your browser.
Before we jump into React, let’s first have a quick overview of how JavaScript works internally.

Chapter 1: JavaScript Internal Working - Quick Overview

Before diving into React, it’s important to understand how JavaScript works behind the scenes.

When you run JavaScript in the browser, it’s executed by a JavaScript engine (like Chrome’s V8). The engine first parses your code into an Abstract Syntax Tree (AST), then uses a Just-In-Time (JIT) compiler to convert it into optimized machine code for efficient execution.
JavaScript is single-threaded, executing one task at a time via the Call Stack. Asynchronous operations such as API calls, timers, or DOM events are handled using Web APIs and the Event Loop, allowing tasks to run in the background without blocking the main thread.
Each function runs in its own execution context, which tracks variables and scope. These contexts form a scope chain, enabling closures and consistent access to variables across nested functions.

Chapter 2: Writing React Components

React applications are built using components - self-contained, reusable pieces of code that describe what the user interface should look like. Think of components as LEGO blocks: each one serves a specific purpose and can be combined with others to create complex structures.

function Welcome(props) {
  const [count, setCount] = useState(0);

  return (
    <div>
      <h1>Hello, {props.name}!</h1>
      <button onClick={() => setCount(count + 1)}>
        Clicked {count} times
      </button>
    </div>
  );
}

This simple component demonstrates several key React concepts:
JSX,Props,State,Event Handlers.

Now let us understand the component lifecycle:
Every React component goes through a series of phases from the time it’s created until it’s removed from the DOM. These phases collectively are called the component lifecycle, and they let you run code at specific points, like fetching data or cleaning up resources.

1.Class Component Lifecycle

Mounting (Creation): When the component is first added to the DOM.
constructor() → initialize state and bind methods
render() → returns JSX
componentDidMount() → runs after the component is added
Updating: When state or props change, triggering a re-render.
render() → creates updated UI
componentDidUpdate() → runs after updates
Unmounting: When the component is removed from the DOM.
componentWillUnmount() → cleanup tasks like removing listeners

2.Functional Component Lifecycle (with Hooks)

Mounting: Runs after the first render.

useEffect(() => { … }, [])

Updating: Runs whenever dependencies change.

useEffect(() => { … }, [dependencies])

Unmounting: Runs cleanup code before the component is removed.

useEffect(() => { return () => { … } }, [])

Chapter 3: JSX - The Bridge Between JavaScript and HTML

JSX (JavaScript XML) is a syntax extension that allows you to write HTML like code directly in JavaScript. While it looks like HTML, JSX is actually syntactic sugar that gets transformed into regular JavaScript function calls.

// This JSX code...
const element = <h1 className="greeting">Hello, World!</h1>;

// ...becomes this JavaScript:
const element = React.createElement(
  'h1',
  { className: 'greeting' },
  'Hello, World!'
);

The React.createElement() function is the heart of React's element creation system. It takes three parameters:

Type: The element type (string for HTML elements, function for components)
Props: An object containing attributes and event handlers
Children: Child elements or text content

Chapter 4: What Babel Actually Does

Babel is a JavaScript transpiler that mainly handles syntax transformations, like converting JSX or modern ES6+ JavaScript into code browsers can understand. Its core tasks are:

Parsing: Converts your code into an Abstract Syntax Tree (AST)
Transformation: Converts JSX elements into React.createElement() calls
Code Generation: Outputs browser-compatible JavaScript

Polyfills are related but separate they are pieces of code that add missing JavaScript features (like Promise, Array.from, Object.assign) in older browsers. Babel can inject polyfills via tools like "@babel/preset-env" or core-js, but polyfills aren’t the main thing Babel does; they are optional and usually configured explicitly.

// Before Babel (what you write):
function App() {
  return (
    <div>
      <h1>My App</h1>
      <Button onClick={handleClick}>Click me!</Button>
    </div>
  );
}

// After Babel (what the browser receives):
function App() {
  return React.createElement(
    'div',
    null,
    React.createElement('h1', null, 'My App'),
    React.createElement(Button, { onClick: handleClick }, 'Click me!')
  );
}

Chapter 5: Webpack – The Module Bundler

After Babel transforms your code, you still need a way to bundle all your files JavaScript, CSS, images into something the browser can load efficiently. That’s where Webpack comes in.

What Webpack does:

Bundles modules: Combines all your JS files and dependencies into one (or a few) bundle files.
Handles assets: Can process CSS, images, fonts, and more using loaders.
Optimizes code: Supports minification, tree-shaking, and code splitting to make your app faster.
Works with plugins: Adds extra features like HTML generation, environment variables, and caching.

In short, Babel transforms your code, and Webpack packages it all together so the browser can understand and run your app efficiently.

Chapter 6: The Virtual DOM - React's Secret Weapon

The Virtual DOM is React's most innovative feature, a lightweight, in-memory representation of the real DOM. Instead of directly manipulating the browser's DOM (which is slow), React creates and maintains a virtual copy in JavaScript memory.

The Virtual DOM process involves several steps:

Initial Render: React creates a complete Virtual DOM tree representing your entire UI
State Changes: When data changes, React creates a new Virtual DOM tree
Diffing: React compares the new tree with the previous one
Reconciliation: Only the differences are applied to the real DOM

The Reconciliation Algorithm
React's reconciliation algorithm is what makes the Virtual DOM efficient. It uses a sophisticated diffing process to minimize DOM updates:

Element Type Comparison: If two elements have different types (e.g., vs ), React tears down the old tree and builds a new one from scratch.
Same Type Elements: For elements of the same type, React keeps the same DOM node and only updates the changed attributes.
List Reconciliation: React uses the key prop to identify which items have changed, been added, or removed in lists, making updates more efficient.

Chapter 7: React Fiber - The Modern Engine

React Fiber is a complete rewrite of React's core algorithm, introduced in React 16. It addresses the limitations of the original "stack reconciler" by enabling incremental rendering.

Why Fiber Was Necessary
The original React reconciler had a problem: it worked synchronously, meaning once it started updating the UI, it couldn't be interrupted. For complex applications, this could cause the browser to freeze, making the app feel unresponsive.
Fiber solves this by:

Breaking work into units: Each component update becomes a unit of work that can be paused and resumed
Prioritizing updates: User interactions get higher priority than background updates
Enabling concurrent features: Multiple updates can be worked on simultaneously

Fiber Architecture
Each component in your app corresponds to a fiber node - a JavaScript object that contains:

Type: The component type
Props: The component's properties
State: The component's internal state
Child/Sibling pointers: Links to other fiber nodes

These fiber nodes form a fiber tree that mirrors your component hierarchy, allowing React to traverse and update components efficiently.

Chapter 8: State Management and Data Flow

React follows a unidirectional data flow.
Data flows down from parent components to children through props,
while changes flow up through callback functions.
State vs Props

State:

Internal to a component
Can be modified by the component itself
Changes trigger re-renders
Managed with useState (functional) or setState (class)

Props:

External data passed from parent components
Read-only within the receiving component
Enable component reusability
Can include children
Changes come from the parent component

Chapter 9: The Complete React Rendering Process

Let’s put everything together and see what happens when you run a React application.

Step 1: Build Process

You write React components using JSX and modern JavaScript.
Babel transforms your code into React.createElement() calls.
Webpack (or another bundler) packages all your files for the browser.

Step 2: Initial Render

React creates the initial Virtual DOM tree representing your UI.
The Reconciler converts the Virtual DOM into real DOM elements.
The browser displays your application.

Step 3: User Interactions and Updates

When a user interacts with your app (clicks, types, etc.),
State updates are triggered via setState or hook updaters.
React schedules a re-render using Fiber’s scheduler.
A new Virtual DOM tree is created.
The diffing algorithm compares the old and new Virtual DOM trees.
The Reconciler applies only the minimal necessary changes to the real DOM.
The browser updates just the parts of the UI that changed.

Step 4: Fiber Work Loop

React Fiber breaks work into units that can be paused and resumed.
High-priority updates (like user input) are handled first.
Less urgent work is paused and completed later, keeping the app responsive.

In short, React transforms your code → builds a virtual representation → efficiently updates the browser using reconciliation and Fiber → keeps your UI fast and responsive.

Chapter 10: Performance Optimizations

React includes several built-in optimizations that make your apps fast:

Batching Updates React automatically batches multiple state updates that happen in the same event handler, reducing the number of re-renders.
Component Memoization React can skip re-rendering components when their props haven't changed, using techniques like React.memo() and useMemo().
Lazy Loading Components can be loaded on-demand using React.lazy() and Suspense, reducing initial bundle size.

Wrapping It All Up

Now that we’ve walked through the journey from writing JSX to seeing your app in the browser, you have a clear picture of what’s happening behind the scenes. React isn’t just magic it’s a carefully designed system with Babel transforming your code, Webpack bundling it, the Virtual DOM and Fiber keeping updates fast, and state and props managing the flow of data.

Understanding this gives you a huge advantage. You can write cleaner code, debug smarter, and even optimize your app like a pro.

So, the next time you click “save” and see your UI update, take a moment to appreciate the orchestra of processes happening under the hood. The better you understand this internal flow, the more powerful and confident you’ll be as a React developer.

If you found this helpful, don’t forget to like, comment, and follow. I’ll be posting more blogs breaking down JavaScript, React, and frontend internals in an easy to understand way. Let’s keep learning together, Happy Coding!