DEV Community: Sudhanshu code

# From JavaScript to Node.js: Understanding What Really Happens Behind the Scenes (Part 4.3A.1)

Sudhanshu code — Fri, 24 Jul 2026 12:17:23 +0000

# Module Resolution Algorithm (Part 1): How Node.js Finds the Right Module

In the previous article, we explored one of the most fascinating parts of Node.js—the hidden Module Wrapper Function. We learned that every CommonJS module is wrapped inside a function before execution, and we also discovered that require() is not a JavaScript feature. It is provided by the Node.js runtime.

But a very important mystery still remains.

When we write:

const fs = require("fs");

const math = require("./math");

how does Node.js know where these modules are located?

How does it decide whether "fs" is a built-in module or a file inside your project?

Why does require("./math") work even if you don't write .js?

And what happens internally before your code starts executing?

The answer lies inside one of Node.js's most important systems:

The Module Resolution Algorithm

Understanding this algorithm is essential because every Node.js application uses it hundreds or even thousands of times while starting.

What is Module Resolution?

The word resolution simply means:

Finding the actual file represented by the string passed to require().

Suppose you write:

require("./math");

To you, "./math" looks like a file.

But for Node.js, it is initially nothing more than a string.

"./math"

Node cannot execute a string.

It needs the real file.

So its first job is to answer one question:

"Which exact file should I load?"

The complete process of converting the string inside require() into an actual file on disk is called Module Resolution.

Why Does Node Need a Resolution Algorithm?

Imagine a project like this:

project/

├── app.js
├── math.js
├── database.js
├── auth.js
└── utils/
    ├── logger.js
    └── helper.js

Now look at these statements.

require("./math");

require("./database");

require("./utils/logger");

require("fs");

require("express");

All of them look similar.

But internally they are completely different.

Some point to your own files.

Some point to Node's built-in modules.

Some point to packages installed using npm.

Node cannot treat them all the same.

It must identify what type of module you are requesting before loading it.

This decision-making process is the first stage of Module Resolution.

Three Types of Modules

Node.js classifies modules into three categories.

Modules

│

├── Core Modules

├── Local Modules

└── Third-Party Modules

Every require() call belongs to one of these categories.

Let's understand each one.

1. Core Modules

Core Modules are modules that come bundled with Node.js itself.

Examples include:

fs
http
https
path
crypto
stream
events
os
url
zlib
buffer

These modules are already part of the Node.js runtime.

You never install them.

You simply write:

const fs = require("fs");

and Node immediately understands what you mean.

Why Are They Called Core Modules?

Because they are part of Node's core source code.

If you install Node.js today,

modules like:

fs

path

http

crypto

are already present inside the runtime.

This is why commands like:

npm install fs

make no sense.

The module already exists.

How Does Node Recognize a Core Module?

Suppose your program contains:

require("fs");

Node starts its resolution process.

First it checks:

"Is this the name of a Core Module?"

If the answer is YES...

the search stops immediately.

Node loads the internal implementation.

No filesystem search occurs.

No node_modules lookup occurs.

No disk traversal happens.

The module is loaded directly.

Conceptually the flow looks like this:

require("fs")

↓

Core Module?

↓

YES

↓

Load Internal Implementation

↓

Return module.exports

This is one reason Core Modules load very quickly.

Is `fs` Written in JavaScript?

Not entirely.

Many Core Modules are implemented using a combination of:

JavaScript
C++
Native Operating System APIs

For example:

fs.readFile()

looks like an ordinary JavaScript function.

But internally the request travels through:

JavaScript

↓

Node API

↓

C++ Binding

↓

libuv

↓

Operating System

↓

Disk

We've already studied this architecture in Part 2.

Module Resolution simply decides which module should receive your request.

2. Local Modules

Local Modules are modules that belong to your own project.

Example:

project/

├── app.js

└── math.js

Inside app.js:

const math = require("./math");

Notice something important.

The path begins with:

./

That small symbol completely changes Node's behavior.

Instead of checking Core Modules,

Node immediately understands:

"This module is inside the current project."

What Does `./` Mean?

./

means:

Current Directory

Suppose your project looks like this:

project/

├── app.js

└── math.js

Current file:

app.js

Current directory:

project/

Therefore:

require("./math");

means:

project/math

Node now begins searching for the file.

Parent Directory

Now consider another project.

project/

├── src/

│   ├── app.js

│   └── utils/

│       └── math.js

Inside app.js:

require("./utils/math");

Node interprets this as:

Current Folder

↓

utils

↓

math

Everything is relative to the file that is currently executing.

Going One Level Up

Suppose you are inside:

src/routes/app.js

and want to access:

src/utils/math.js

You write:

require("../utils/math");

Here:

..

means:

Parent Directory

Internally Node performs:

routes

↓

Go Up

↓

src

↓

utils

↓

math.js

Going Multiple Levels Up

You can continue moving upward.

require("../../config/database");

means:

Current Folder

↓

Parent

↓

Parent

↓

config

↓

database

This is exactly how your operating system navigates directories.

Node simply follows the filesystem hierarchy.

Relative Paths vs Absolute Paths

There are two ways to locate files.

Relative Path

require("./utils/math");

Depends on the current module's location.

Absolute Path

require("C:/Projects/Bank/src/utils/math");

or on Linux:

require("/home/user/project/src/utils/math");

This specifies the complete location.

Although Node supports absolute paths, they are rarely used in production because they make applications difficult to move between systems.

Relative paths keep projects portable and maintainable.

How Does Node Decide?

At this point, Node has learned one important thing.

It asks a very simple question:

Does the string start with ./, ../, or /?

If YES,

it is treated as a file path.

If NO,

Node first checks whether it is a Core Module.

Only if it is not a Core Module does Node continue searching elsewhere.

This tiny decision is the very first branch in the Module Resolution Algorithm.

It determines the entire loading strategy.

Key Takeaways

After reading this chapter, you should understand:

Module Resolution converts the argument passed to require() into an actual file.
Node classifies modules into Core, Local, and Third-Party modules.
Core Modules are bundled with Node.js and are loaded immediately.
Local Modules begin with ./, ../, or /.
./ means the current directory.
.. means the parent directory.
Relative paths are preferred over absolute paths in production applications.
The first step of the Module Resolution Algorithm is identifying what kind of module you are requesting.

Coming Next

In Part 4.3A.2, we'll continue the journey by answering questions that every backend developer eventually encounters:

Why does require("./math") work without writing .js?
How does Node search for .js, .json, and .node files?
What happens when you require a folder instead of a file?
Why does index.js load automatically?
How does package.json influence Module Resolution?
What is the exact resolution order followed internally by Node.js?

By the end of Part 4.3A.2, you'll understand the complete algorithm Node.js uses before a module is ever executed.

From JavaScript to Node.js: Understanding What Really Happens Behind the Scenes (Part 4.2)

Sudhanshu code — Fri, 24 Jul 2026 12:08:30 +0000

The Hidden World of require(): Module Wrapper Function, module.exports, and exports

In the previous article, we learned why modules exist.

We discovered that every JavaScript file in Node.js is treated as an independent module with its own private scope.

But a much bigger question remains.

When we write:

const math = require("./math");

what actually happens?

Does JavaScript understand require()?

Does the V8 Engine load another file?

Or does Node.js perform some hidden magic?

Let's open the black box.

Is require() a JavaScript Feature?

One of the biggest misconceptions among beginners is this:

"require() is part of JavaScript."

It isn't.

Open your browser console and type:

require("./math");

You'll get something similar to:

ReferenceError: require is not defined

Why?

Because JavaScript itself has no built-in function called require().

The ECMAScript specification—the official definition of JavaScript—doesn't include it.

So where does it come from?

The answer is simple:

require() is created by Node.js, not by JavaScript.

It is part of the Node.js runtime.

Then How Can We Use It in Every File?

This is where Node.js does something brilliant.

Suppose you create a file called:

math.js

containing:

const PI = 3.14159;

function add(a, b) {
return a + b;
}

You wrote only these few lines.

But Node does not execute this file exactly as it appears.

Before execution, Node wraps your code inside another function.

Conceptually, it becomes:

(function (exports, require, module, __filename, __dirname) {

const PI = 3.14159;

function add(a, b) {
return a + b;
}

});

This hidden function is called the Module Wrapper Function.

Node creates it automatically for every CommonJS module.

You never write it yourself.

Why Wrap Every Module?

At first, wrapping every file may seem unnecessary.

But this single design solves multiple problems.

It creates:

A private scope
Module isolation
Access to require
Access to module
Access to exports
Access to __filename
Access to __dirname

Without this wrapper, every variable would become global.

Imagine two files.

const PORT = 3000;

and

const PORT = 5000;

Without isolation, these variables would collide.

Because of the wrapper, each file gets its own execution environment.

Understanding the Wrapper Parameters

Let's examine the hidden function carefully.

(function (
exports,
require,
module,
__filename,
__dirname
) {

// Your code

});

Every parameter has a purpose.

require const fs = require("fs");

require() loads another module.

Node creates this function before your code starts executing.

It is not provided by V8.

module

Every file gets a module object.

Conceptually:

module = {

exports: {}

}

Initially,

module.exports

is simply an empty object.

exports

Another interesting parameter appears.

exports

Many beginners think

exports

and

module.exports

are different objects.

Initially...

they are references to the same object.

Conceptually:

exports
│
▼
{}

▲
│

module.exports

Both variables point to the same object.

Example
exports.name = "Sudhanshu";

Internally this becomes

module.exports.name = "Sudhanshu";

because both references currently point to the same object.

When Do They Become Different?

Suppose you write

exports = {};

Now

exports

points somewhere else.

But

module.exports

still points to the original object.

Visualization:

Initially

exports
│
▼
{}

▲
│

module.exports

After reassignment

exports
│
▼
{}

module.exports
│
▼
{ name: "Sudhanshu" }

They are no longer connected.

This is why Node returns module.exports, not exports.

We'll revisit this in even more detail later.

__filename

Node automatically provides the absolute path of the current module.

Example:

console.log(__filename);

Output:

C:\Projects\BankApp\math.js

Useful for logging and locating resources.

__dirname

Similarly,

console.log(__dirname);

might produce

C:\Projects\BankApp

This is extremely useful when loading files relative to the current module.

What Happens When We Call require()?

Suppose our project looks like this.

project/

├── app.js

└── math.js

math.js

function add(a, b) {
return a + b;
}

module.exports = add;

app.js

const add = require("./math");

console.log(add(2,3));

Now let's follow the execution.

Step 1

Node begins executing

app.js

inside its own wrapper function.

Step 2

Execution reaches

require("./math")

Node recognizes that another module is required.

Step 3

Node resolves the path.

It asks:

Where is "./math"?

Node tries to locate the corresponding file.

Eventually it finds

math.js
Step 4

Node reads the contents of the file.

At this point,

it has only plain text.

function add(a,b){
return a+b;
}

module.exports = add;

Nothing has executed yet.

Step 5

Before execution,

Node wraps the file.

Conceptually:

(function(exports, require, module, __filename, __dirname){

function add(a,b){
return a+b;
}

module.exports = add;

});

Notice that the wrapper is created before V8 executes the module.

Step 6

Now V8 executes the wrapped function.

During execution,

Node updates

module.exports

to reference

add

At the end of execution,

the module object looks conceptually like:

module = {

exports: add

}
Step 7

require() returns

module.exports

Therefore

const add = require("./math");

becomes conceptually equivalent to

const add = module.exports;

Now

add(2,3)

works exactly as expected.

The Complete Flow

Let's summarize everything.

app.js

↓

require("./math")

↓

Resolve File Path

↓

Read File

↓

Wrap Inside Module Function

↓

Create module object

↓

Create exports reference

↓

Provide require()

↓

Provide __filename

↓

Provide __dirname

↓

Execute with V8

↓

Populate module.exports

↓

Return module.exports

↓

Continue app.js

This entire process happens every time a new CommonJS module is loaded.

Why Doesn't V8 Do This?

Because none of this belongs to JavaScript.

V8 understands:

Variables
Functions
Arrays
Objects
Loops
Classes

It does not understand:

Files
Modules
require()
module.exports
__dirname

Those are runtime features provided by Node.js.

This distinction is extremely important.

Key Takeaways

After reading this article, you should understand:

require() is not part of JavaScript.
Node.js injects require() into every CommonJS module.
Every module is wrapped inside a hidden function before execution.
The wrapper creates a private scope.
module.exports is the object that Node actually returns.
exports is initially just another reference to module.exports.
Reassigning exports does not change module.exports.
V8 executes the wrapped function, but the wrapper itself is created by Node.js.
Coming Next

In Part 4.3, we'll go even deeper.

We'll answer questions such as:

How does Node know where to find a module?
Why does require("./math") work without writing .js?
How does Node search node_modules?
What is the Module Resolution Algorithm?
Why is require() synchronous?
What is Module Cache, and why is a module executed only once?
How do Circular Dependencies work internally?

By the end of Part 4.3, you'll understand the entire lifecycle of a CommonJS module—from the moment you type require() until Node returns the exported value.

From JavaScript to Node.js: Understanding What Really Happens Behind the Scenes (Part 4.1)

Sudhanshu code — Fri, 24 Jul 2026 12:07:15 +0000

Node.js Modules Explained from Scratch — Why Do Modules Even Exist?

If you've been writing Node.js for even a few days, you've probably seen code like this:

const fs = require("fs");
const express = require("express");
const path = require("path");

Or maybe you've written your own module:

const math = require("./math");

Most tutorials stop here.

They teach how to use require(), but very few explain why modules exist in the first place.

In this article, we're not going to start with require().

Instead, we're going to start with a much more fundamental question.

Why were modules invented at all?

Because once you understand that, everything else in Node.js modules starts making sense.

Imagine Building Everything in One File

Let's say you're creating a banking application.

At first, everything feels simple.

function login() {}

function logout() {}

function transferMoney() {}

function checkBalance() {}

function createAccount() {}

function updateProfile() {}

function deleteAccount() {}

function sendOTP() {}

function generateToken() {}

function connectDatabase() {}

Looks manageable.

Now imagine your application grows.

After six months, your file contains:

Authentication
Database Logic
Payment Logic
Email Service
Notifications
User Management
Admin Dashboard
Reports
Logging
Validation
Utility Functions

One file becomes

app.js

25,000 lines

Can one developer understand it easily?

No.

Can ten developers work on the same file?

Also no.

Can bugs be found quickly?

Again, no.

So the problem wasn't JavaScript.

The problem was organization.

Software Is Built by Teams

Modern software isn't written by one person.

Imagine a company with 40 backend engineers.

If everyone edits the same file...

app.js

chaos begins.

Developer A changes authentication.

Developer B edits payments.

Developer C modifies notifications.

Developer D updates database code.

Soon everyone is editing the same file.

Conflicts become unavoidable.

Software engineering needed a better way to organize code.

That idea became modules.

What Is a Module?

The simplest definition is:

A module is a self-contained piece of code responsible for one specific task.

Instead of writing everything together...

we divide the application into small independent files.

Example:

project/

├── app.js

├── auth.js

├── payment.js

├── database.js

├── email.js

├── utils.js

└── logger.js

Every file has a single responsibility.

This makes applications easier to understand, test, debug, and maintain.

Modules Are Not a Node.js Feature

This surprises many beginners.

People often say:

"Modules are a Node.js concept."

Not exactly.

The idea of modules is much older than Node.js.

Many programming languages support modular programming.

Examples include:

Java Packages
Python Modules
C Libraries
C++ Header Files
Rust Crates
Go Packages

Node.js adopted this idea for JavaScript.

JavaScript Before Modules

When JavaScript was created in 1995...

there were no modules.

The language was designed to make web pages interactive.

Most websites contained only a few lines of JavaScript.

For example:

alert("Welcome");

button.onclick = function () {
alert("Clicked");
};

Nobody imagined JavaScript would one day power:

Netflix
PayPal
LinkedIn
Uber
VS Code
Discord

Because applications were tiny...

modules weren't considered necessary.

Then JavaScript Started Growing

Around the mid-2000s, developers started building larger web applications.

Instead of

200 lines

applications became

20,000 lines

50,000 lines

100,000+ lines

Developers desperately needed code organization.

But JavaScript still had no official module system.

People started inventing their own solutions.

Before Node.js, Developers Used the Global Scope

Suppose you have two files.

math.js

function add(a, b) {
return a + b;
}

app.js

console.log(add(2,3));

Seems fine.

Until another developer writes

function add() {}

in another file.

Now both functions exist globally.

Which one should JavaScript use?

Nobody knows.

This became known as Global Namespace Pollution.

Everything lived in one shared global environment.

Large applications became difficult to maintain.

The Global Scope Problem

Imagine one whiteboard shared by an entire company.

Everyone writes on the same board.

Soon:

names collide
variables overwrite each other
debugging becomes painful
maintenance becomes difficult

The JavaScript global scope behaved similarly.

Modules solved this problem.

How Modules Solve the Problem

Instead of one giant shared environment...

every file receives its own private scope.

Imagine:

math.js

↓

Private Room
auth.js

↓

Private Room
database.js

↓

Private Room

Each file can safely define:

const PORT = 3000;

without affecting another file.

This isolation is one of the biggest advantages of modules.

Every File Is a Module in Node.js

One of the most beautiful design decisions in Node.js is incredibly simple.

Every JavaScript file is automatically treated as a separate module.

Suppose we have:

project/

├── app.js

└── math.js

math.js

const PI = 3.14159;

function add(a, b) {
return a + b;
}

At first glance, you might expect both PI and add() to be available everywhere.

They are not.

Open another file.

app.js

console.log(PI);

Output:

ReferenceError: PI is not defined

Why?

Because every file has its own scope.

This is one of Node.js's most important design decisions.

Why Doesn't One File See Another File's Variables?

Think about a house.

Every room has its own door.

Just because your bedroom contains a table...

doesn't mean the kitchen automatically has access to it.

Node.js modules work similarly.

Each file is isolated.

Nothing leaves that file unless you explicitly allow it.

That is where module.exports enters the picture.

We'll study that in the next article.

How Does Node Know a File Is a Module?

This is where things become interesting.

When Node loads

math.js

it does not execute the file exactly as you wrote it.

Internally...

Node wraps your code before executing it.

Something similar to this happens behind the scenes:

(function (exports, require, module, __filename, __dirname) {

// Your code lives here

});

This is called the Module Wrapper Function.

We'll explore it deeply in Part 4.2.

For now, remember one important idea:

Every file receives its own private execution environment.

That single design decision solves a huge number of software engineering problems.

Benefits of Modules

Modules provide much more than cleaner code.

They enable:

Better code organization
Reusability
Encapsulation
Easier testing
Team collaboration
Maintainability
Separation of concerns
Reduced naming conflicts
Improved scalability

These principles apply across almost every modern programming language.

Key Takeaways

After reading this article, you should understand that:

Modules were created to solve software organization problems.
JavaScript originally had no module system.
Large applications exposed the limitations of the global scope.
Node.js treats every JavaScript file as a separate module.
Every module has its own private scope.
Variables inside one file are not automatically visible in another.
Node internally wraps every module before executing it.
This wrapper creates isolation and lays the foundation for require() and module.exports.
Coming Next

In Part 4.2, we'll open the black box and answer questions that almost every Node.js developer asks:

What actually happens when you write require("./math")?
Is require() part of JavaScript or Node.js?
What is the Module Wrapper Function?
Why do exports and module.exports exist?
How does one module communicate with another?
What does Node execute behind the scenes before your code runs?

We'll move from using modules...

to understanding how Node.js builds its entire module system internally.

From JavaScript to Node.js: Understanding What Really Happens Behind the Scenes (Part 3)

Sudhanshu code — Fri, 24 Jul 2026 12:05:20 +0000

From JavaScript to Node.js: Understanding What Really Happens Behind the Scenes (Part 3)

Synchronous vs Asynchronous Node.js: What Really Happens Inside `fs.readFile()`?

In the previous article, we learned that Node.js is much more than the V8 engine.

We discovered that a simple file operation travels through multiple layers:

JavaScript
    ↓
V8 Engine
    ↓
Node APIs
    ↓
C++ Bindings
    ↓
libuv
    ↓
Operating System
    ↓
Hardware

But one important question still remains unanswered.

If reading a file requires communicating with the operating system and the storage device...

Why doesn't Node.js freeze while waiting for the file?

To answer that, we first need to understand one of the most important ideas in computer science.

What Does "Blocking" Actually Mean?

Most tutorials define blocking like this:

"Blocking means the program waits."

That definition is correct...

but it doesn't explain what is actually waiting.

Let's look deeper.

Consider this program.

console.log("Start");

const fs = require("fs");

const data = fs.readFileSync("message.txt", "utf8");

console.log(data);

console.log("End");

Many developers say:

"Node waits."

But technically, that's not what happens.

The current JavaScript execution cannot continue because the current function has not finished.

The JavaScript thread is occupied.

Imagine the execution like a single employee working at a desk.

Current Task

↓

Read File

↓

Not Finished Yet

Until that task finishes...

the employee cannot start another task.

This is called blocking.

Understanding the Call Stack

Before discussing asynchronous programming, we need to understand the Call Stack.

The Call Stack is a data structure that keeps track of which JavaScript function is currently executing.

Imagine it as a stack of books.

Top

console.log()

main()

Bottom

Whenever a function starts, it is pushed onto the stack.

When it finishes, it is removed.

Only the function at the top of the stack can execute.

JavaScript executes one stack frame at a time.

This is one of the reasons JavaScript is called single-threaded.

Example

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

console.log("Start");

greet();

console.log("End");

Call Stack visualization

console.log("Start")

↓

Removed

↓

greet()

↓

console.log("Hello")

↓

Removed

↓

console.log("End")

Only one frame executes at a time.

There is no parallel execution happening here.

What Happens Inside `readFileSync()`?

Let's follow the execution carefully.

const fs = require("fs");

console.log("1");

const text = fs.readFileSync("notes.txt", "utf8");

console.log(text);

console.log("2");

Execution begins.

console.log("1")

↓

Output

1

Next comes

fs.readFileSync(...)

Node sends the request down the runtime layers.

JavaScript

↓

Node API

↓

C++ Binding

↓

Operating System

↓

SSD

At this moment...

JavaScript cannot continue.

The Call Stack still contains

readFileSync()

Until it returns,

this line

console.log("2");

cannot execute.

The result arrives.

The stack becomes free.

Execution continues.

Final Output

1

(File Content)

2

Nothing surprising happened.

The execution simply stopped until the file arrived.

This is synchronous execution.

Why Is It Called Synchronous?

Because every operation happens in sequence.

Task A

↓

Complete

↓

Task B

↓

Complete

↓

Task C

Nothing jumps ahead.

Nothing overlaps.

Every step waits for the previous one.

Now Let's Look at `readFile()`

const fs = require("fs");

console.log("1");

fs.readFile("notes.txt", "utf8", (err, text) => {
    console.log(text);
});

console.log("2");

Many beginners imagine that JavaScript starts another thread.

It doesn't.

Let's see the real flow.

Step 1

console.log("1")

Output

Step 2

JavaScript reaches

fs.readFile(...)

Node prepares a native request.

The request moves through

Node API

↓

C++

↓

libuv

↓

Operating System

Notice something important.

The file has not been read yet.

Only the request has been submitted.

Step 3

At this point...

JavaScript has nothing left to do with that request.

The current function finishes immediately.

The Call Stack becomes free.

Now JavaScript executes

console.log("2");

Output becomes

1

2

The file still hasn't arrived.

Step 4

The operating system eventually finishes reading the file.

The data returns.

SSD

↓

Operating System

↓

libuv

↓

Node Runtime

The callback is now ready.

Later, when JavaScript is free to execute it, the callback runs and prints the file.

Final Output

1

2

Hello World

This is why asynchronous code appears to "continue."

JavaScript didn't keep reading the file.

It simply delegated that responsibility.

The Biggest Misconception

People often say

"Node.js performs asynchronous operations."

That sentence is incomplete.

A better statement is

Node.js delegates long-running operations to the operating system (through libuv and native bindings), allowing JavaScript to continue executing other work while the result is being prepared.

That is the real reason asynchronous programming exists.

Why Doesn't V8 Read the File Directly?

Because V8 was never designed to understand operating systems.

V8 understands JavaScript.

It understands things like

const numbers = [1,2,3];

numbers.map(x => x * 2);

It does not understand

NTFS
ext4
APFS
TCP sockets
DNS
File permissions

Those belong to the operating system.

Node bridges that gap.

Does libuv Read the File?

Another common misconception.

Many developers think

"libuv reads the file."

Not exactly.

In most file operations, the operating system ultimately performs the actual file read.

libuv coordinates the asynchronous workflow, abstracts platform differences, and integrates the result back into Node.js in a consistent way across operating systems.

Think of libuv as an expert traffic controller—not the storage device itself.

Why Is Node.js Fast?

Many articles say

"Node.js is fast because it is asynchronous."

That's only part of the story.

Node.js is fast because it avoids wasting the JavaScript thread waiting for slow I/O operations.

Imagine a restaurant.

One waiter.

One customer asks for coffee.

Brewing coffee takes five minutes.

A poor workflow would have the waiter stand beside the coffee machine doing nothing.

A better workflow is:

Take the order.
Give it to the kitchen.
Serve other customers.
Return when the coffee is ready.

Node.js follows the second model.

The JavaScript thread stays productive.

Synchronous vs Asynchronous

Synchronous	Asynchronous
Blocking	Non-blocking (for the JavaScript thread)
Waits for completion	Delegates work and continues
Simpler control flow	Better scalability for I/O
Can freeze execution	Keeps the thread available for other work

Neither is "better" in every situation.

Sometimes synchronous code is exactly what you need—especially during startup scripts, configuration loading, or command-line tools.

Engineering is about choosing the right tool.

Key Takeaways

After reading this article, you should be able to explain these ideas confidently:

JavaScript executes on a single main thread.
The Call Stack allows only one JavaScript function to execute at a time.
readFileSync() blocks because the current execution cannot continue until it returns.
readFile() submits work to the Node runtime and operating system, allowing JavaScript to continue.
V8 executes JavaScript—it does not understand operating-system resources.
Node.js extends JavaScript by providing native APIs and runtime infrastructure.
libuv helps Node provide efficient, cross-platform asynchronous I/O.

These are not just interview concepts.

They are the foundation of every Express server, every database query, every API request, and every backend application built with Node.js.

Coming Next

In Part 4, we'll explore one of the most misunderstood topics in Node.js:

Modules, require(), module.exports, exports, Module Wrapper Function, and Module Cache

We'll answer questions like:

What actually happens when you write require("fs")?
Is require() a JavaScript feature or a Node.js feature?
Why is every file treated as a separate module?
How does Node avoid loading the same module twice?
What is the Module Wrapper Function?
Why do exports and module.exports sometimes behave differently?

By the end of Part 4, you'll understand Node.js modules from the inside out—not just how to use them, but how they work.

From JavaScript to Node.js: Understanding What Really Happens Behind the Scenes (Part 2)

Sudhanshu code — Fri, 24 Jul 2026 12:04:40 +0000

From JavaScript to Node.js: Understanding What Really Happens Behind the Scenes (Part 2)

What Actually Happens After You Run `node app.js`?

In the previous article, we answered one important question:

Why does Node.js exist?

Now we're going to answer a much deeper question.

What actually happens when you execute this command?

node app.js

Most developers know that "Node executes JavaScript."

But that's only the surface.

Behind this simple command, thousands of lines of C++, operating system calls, memory allocation, and multiple software layers start working together.

Understanding this journey completely changed the way I think about backend development.

Let's follow that journey.

Step 1 — Your JavaScript File Is Just Text

Suppose your application looks like this:

console.log("Application Started");

Before execution, app.js is nothing more than a text file stored on your SSD or HDD.

The computer does not see JavaScript.

It only sees bytes.

Imagine your file as:

Storage
│
├── app.js
│
└── Contains plain text characters

Nothing has executed yet.

Step 2 — The Operating System Starts Node.js

When you type

node app.js

your terminal doesn't magically understand JavaScript.

Instead, your operating system does something similar to this:

Windows / Linux / macOS

↓

Find node executable

↓

Create a new process

↓

Allocate memory

↓

Load Node.js into RAM

↓

Start execution

This is extremely important.

The operating system starts Node.js first.

Node.js starts your JavaScript later.

Many beginners think:

JavaScript

↓

Node

Reality is:

Operating System

↓

Node Process

↓

V8

↓

JavaScript

What Is a Process?

A process is simply a running instance of a program.

Example:

Chrome.exe

↓

Running

↓

Chrome Process

Similarly,

node app.js

↓

Running

↓

Node Process

Every process has:

its own memory
its own call stack
its own heap
its own resources
its own execution context

This isolation is one reason why applications don't accidentally overwrite each other's memory.

Step 3 — Node Initializes the Runtime

After the process starts, Node initializes several internal systems.

These include:

V8 Engine
Memory
Event Loop
Timers
Internal Modules
libuv
Environment Variables
Process Object

Only after all of these are prepared does Node begin loading your JavaScript.

The Biggest Misconception About Node.js

Many developers imagine this:

JavaScript

↓

Node.js

↓

Computer

This is incomplete.

The real architecture is much larger.

Your JavaScript
        │
        ▼
      V8 Engine
        │
        ▼
 Node.js APIs
        │
        ▼
 C++ Bindings
        │
        ▼
      libuv
        │
        ▼
Operating System
        │
        ▼
Hardware

Every layer has a different responsibility.

Let's understand every one.

Layer 1 — V8 Engine

The V8 Engine is Google's open-source JavaScript engine.

Its responsibility is very small but extremely important.

It executes JavaScript.

Nothing more.

V8 understands:

Variables
Objects
Arrays
Functions
Classes
Loops
Promises
Closures
Arithmetic
Memory management
Garbage Collection

Example:

const a = 10;
const b = 20;

console.log(a + b);

V8 can execute this entirely on its own.

No operating system interaction is required.

What V8 Cannot Do

Now consider this code.

const fs = require("fs");

fs.readFile("data.txt");

Can V8 read files?

No.

Can V8 create an HTTP server?

No.

Can V8 open TCP sockets?

No.

Can V8 communicate with the operating system?

No.

This surprises many beginners.

V8 is not Node.js.

It is only a JavaScript engine.

Layer 2 — Node APIs

This is where Node becomes powerful.

Node provides JavaScript with additional capabilities.

Examples include:

fs

http

https

path

crypto

stream

dns

os

net

child_process

These are called Node APIs or Node Core Modules.

They are not JavaScript language features.

They exist because Node adds them.

For example,

fs.readFile()

is not part of JavaScript.

Node provides it.

Without Node,

this API doesn't exist.

Layer 3 — C++ Bindings

Now imagine this line.

fs.readFile("data.txt");

JavaScript itself has absolutely no idea how to read a file.

Think about it.

How can JavaScript know:

where the file is stored?
which SSD sector contains it?
how Windows reads files?
how Linux reads files?

It can't.

So Node translates JavaScript into native code.

This translation layer is called C++ Bindings.

Think of it like a translator.

JavaScript

↓

"I want to read a file."

↓

C++

↓

Operating System understands.

Node itself is largely written in C++.

These bindings connect JavaScript with native system functions.

Layer 4 — libuv

This is probably the most important component of Node.js.

And surprisingly...

many Node developers never learn what it actually is.

So what is libuv?

libuv is a cross-platform asynchronous I/O library written in C.

That definition sounds intimidating.

Let's simplify it.

Imagine Node directly talking to Windows.

Node

↓

Windows APIs

Now imagine the same Node application running on Linux.

Linux has completely different system APIs.

Node would need separate implementations for:

Windows
Linux
macOS
BSD
Unix

That would be a maintenance nightmare.

Instead,

Node talks only to libuv.

Node

↓

libuv

↓

Windows

Node

↓

libuv

↓

Linux

Node

↓

libuv

↓

macOS

libuv hides operating system differences.

Your JavaScript remains identical.

Layer 5 — Operating System

Now the request finally reaches the operating system.

Suppose your code is

fs.readFile("photo.png");

The OS now becomes responsible for:

locating the file
checking permissions
communicating with the file system
requesting data from storage
returning the bytes

Node itself never searches your SSD.

The operating system does.

Layer 6 — Hardware

Finally...

the storage device receives the request.

SSD

↓

Read bytes

↓

Operating System

↓

libuv

↓

Node

↓

JavaScript Callback

Only after this entire journey does your JavaScript receive the file.

Complete Flow

Let's put everything together.

Suppose we execute:

const fs = require("fs");

fs.readFile("hello.txt", (err, data) => {
    console.log(data.toString());
});

The internal flow looks like this.

JavaScript

↓

V8 executes JavaScript

↓

Node API (fs)

↓

C++ Binding

↓

libuv

↓

Operating System

↓

SSD

↓

Operating System

↓

libuv

↓

C++ Binding

↓

JavaScript Callback

↓

console.log()

Notice something interesting.

The request travels down through every layer.

The result travels back up through every layer.

Node acts as a bridge between JavaScript and the operating system.

An Important Observation

Many tutorials say:

"Node.js executes JavaScript."

Technically...

that's not completely accurate.

A more precise statement is:

The V8 Engine executes JavaScript. Node.js provides the runtime environment, native APIs, C++ bindings, and operating system integration that allow JavaScript to perform tasks beyond the language itself.

This distinction matters.

Understanding it changes how you see Node forever.

Final Thoughts

Today we followed a single JavaScript statement all the way from your code to the hardware.

We learned that Node.js is not simply "JavaScript outside the browser."

It is a carefully designed runtime built from multiple independent components working together:

V8 executes JavaScript.
Node APIs expose new capabilities.
C++ Bindings translate JavaScript into native operations.
libuv provides cross-platform asynchronous I/O.
The Operating System performs system-level work.
The Hardware ultimately executes the request.

Every file read...

every HTTP request...

every database connection...

every Express server...

travels through this architecture.

Understanding these layers is the difference between using Node.js...

and understanding Node.js.

Coming Next

In Part 3, we'll answer one of the most misunderstood questions in backend development:

Why is Node.js asynchronous, and what really happens inside fs.readFile() versus fs.readFileSync()?

We'll explore:

Blocking vs Non-Blocking I/O
Synchronous execution
Asynchronous execution
The Event Loop (from first principles)
Why Node.js doesn't stop while waiting for I/O
Where libuv actually fits into the story

Instead of memorizing "Node is asynchronous," we'll understand why it works that way.

From JavaScript to Node.js: Understanding What Really Happens Behind the Scenes (Part 1)

Sudhanshu code — Fri, 24 Jul 2026 12:03:43 +0000

From JavaScript to Node.js: Understanding What Really Happens Behind the Scenes (Part 1)

Stop Memorizing Node.js. Start Understanding It.

"I don't want to learn Node.js just to build APIs. I want to understand what actually happens behind the scenes."

That thought completely changed the way I approached backend development.

Today, we live in a world where AI can generate hundreds of lines of code in seconds. We can build applications faster than ever before. But there is one thing AI cannot replace—our understanding of how software actually works.

Anyone can copy code.

Anyone can ask ChatGPT to generate an Express server.

But when production crashes at 2 AM...
when memory usage suddenly spikes...
when thousands of requests hit your server...
or when an interview asks, "What actually happens after running node app.js?"...

Only fundamentals can help.

This article is not about learning Node.js syntax.

It is about understanding why Node.js exists, how it works internally, and how JavaScript reaches your hardware.

If you're willing to learn from first principles, let's begin.

Every Computer Speaks Only One Language

Before learning Node.js, we need to understand something even more fundamental.

What language does a computer understand?

Not JavaScript.

Not Java.

Not Python.

Not C++.

A computer understands only one language:

Machine Language

1010101010
1100101011
0001110101

Everything eventually becomes binary.

When your CPU executes instructions, it is not reading JavaScript.

It is reading machine instructions represented as 0s and 1s.

This immediately raises an important question.

If computers only understand binary...

How do programming languages work?

Why Programming Languages Exist

Imagine writing an entire operating system using binary.

Instead of writing

console.log("Hello World");

you would write thousands of bits manually.

Impossible.

Programming languages were created to allow humans to communicate with computers more efficiently.

Languages like

C
C++
Java
Python
JavaScript
Rust
Go

are human-friendly.

But computers still require machine code.

Something must translate our code.

The Translator Between Humans and Computers

Different languages use different translation models.

Let's understand three important ones.

C Language

Suppose we write:

#include <stdio.h>

int main() {
    printf("Hello World");
}

Your CPU cannot execute this file directly.

It first goes through a compiler.

hello.c
      │
      ▼
 GCC Compiler
      │
      ▼
Machine Code (.exe)
      │
      ▼
CPU

The compiler converts the entire program into machine code before execution begins.

This is one reason why C programs are extremely fast.

The CPU executes machine instructions directly.

Java

Java follows a different approach.

Main.java
      │
      ▼
javac
      │
      ▼
Bytecode (.class)
      │
      ▼
JVM
      │
      ▼
Machine Code
      │
      ▼
CPU

Instead of producing native machine code immediately, Java first creates Bytecode.

The JVM (Java Virtual Machine) then converts bytecode into machine instructions for the current operating system.

That's why Java follows the famous principle:

Write Once, Run Anywhere.

Windows has its own JVM.

Linux has its own JVM.

macOS has its own JVM.

Your Java code remains the same.

JavaScript Is Different

Now comes JavaScript.

Suppose we write:

console.log("Hello World");

Can the CPU execute this?

No.

The CPU still understands only binary.

So who executes JavaScript?

The answer depends on where JavaScript is running.

JavaScript Inside the Browser

Every modern browser ships with its own JavaScript engine.

Examples include:

Browser	JavaScript Engine
Chrome	V8
Microsoft Edge	V8
Firefox	SpiderMonkey
Safari	JavaScriptCore
Opera	V8

A JavaScript engine's primary job is simple:

Execute JavaScript code as efficiently as possible.

When you open a website,

JavaScript
      │
      ▼
JavaScript Engine
      │
      ▼
Machine Code
      │
      ▼
CPU

The engine converts your JavaScript into instructions that the processor can execute.

Chrome uses V8.

Firefox uses SpiderMonkey.

Safari uses JavaScriptCore.

The language remains JavaScript.

Only the engine changes.

Does JavaScript Behave Differently Across Browsers?

Sometimes.

Not because JavaScript itself changes...

but because browsers expose different APIs and may implement certain features differently.

For example,

window

document

navigator

localStorage

are Browser APIs, not JavaScript language features.

Similarly,

rendering engines,

DOM implementation,

CSS behavior,

and browser optimizations

may vary slightly across browsers.

Modern browsers follow ECMAScript standards closely, so core JavaScript behavior is largely consistent today.

The Problem Before Node.js

Before 2009...

JavaScript had one major limitation.

It could only run inside browsers.

Think about it.

JavaScript could manipulate HTML.

It could respond to button clicks.

It could create animations.

But could JavaScript:

Read files from your computer?
Create an HTTP server?
Listen on port 3000?
Access the operating system?
Build backend applications?

No.

Because browsers intentionally restrict JavaScript.

This restriction is called a sandbox.

Why Browsers Restrict JavaScript

Imagine visiting an unknown website.

Without restrictions, that website could:

Delete your files
Read your passwords
Format your hard drive
Install malware
Access private documents

That would be catastrophic.

Browsers isolate JavaScript inside a secure environment.

Inside a browser, JavaScript receives only browser-related capabilities such as:

window

document

history

location

navigator

fetch

But it cannot freely communicate with your operating system.

This design keeps users safe.

Then Came Ryan Dahl

In 2009, software engineer Ryan Dahl looked at Google's V8 engine and had a simple but powerful idea.

"If V8 can execute JavaScript so efficiently inside Chrome...
why can't it execute JavaScript outside the browser?"

The engine already existed.

It was incredibly fast.

The missing piece was an environment that could provide operating-system capabilities.

That idea eventually became Node.js.

So, What Is Node.js?

One of the biggest misconceptions is:

"Node.js is a programming language."

Wrong.

Another misconception:

"Node.js is a framework."

Also wrong.

The most accurate definition is:

Node.js is a JavaScript runtime environment that embeds Google's V8 JavaScript engine and provides additional APIs for interacting with the operating system.

Let's simplify that.

Node.js contains several important components working together.

Your JavaScript
        │
        ▼
      V8 Engine
        │
        ▼
 Node.js Runtime
        │
        ▼
Operating System
        │
        ▼
Hardware

The V8 engine executes JavaScript.

Node.js provides everything JavaScript needs beyond the language itself.

What Does Node.js Add?

JavaScript alone cannot do this:

fs.readFile(...)

Nor this:

http.createServer(...)

Nor this:

net.createConnection(...)

Those are Node APIs.

Node.js extends JavaScript by exposing operating-system functionality.

Some examples include:

File System (fs)
HTTP (http)
Path (path)
Process (process)
Streams (stream)
Crypto (crypto)
Timers
Networking

Without Node.js, these APIs do not exist.

Browser vs Node.js

Although both execute JavaScript, their environments are completely different.

Browser	Node.js
Runs inside browser	Runs outside browser
Has `window`	Has `global`
Has DOM	No DOM
Can manipulate HTML	Cannot manipulate HTML
Browser APIs	Operating System APIs
Focused on UI	Focused on servers and backend

This explains why the following code works inside Chrome:

alert("Hello");

but fails inside Node.js.

Likewise,

window.location

exists in browsers...

but not in Node.js.

Different environments provide different capabilities.

A Different Way to Think About Node.js

Most tutorials describe Node.js like this:

"Node.js allows JavaScript to run outside the browser."

That statement is true.

But it is incomplete.

A better way to think about it is this:

Node.js is the bridge between JavaScript and your operating system.

Without Node.js,

JavaScript can think.

With Node.js,

JavaScript can act.

It can create servers.

Read files.

Communicate over networks.

Manage processes.

Interact with the operating system.

And eventually power applications used by millions of people.

What's Next?

So far, we've answered one important question:

Why does Node.js exist?

In the next part, we'll answer a much deeper one:

What actually happens after running node app.js?

We'll explore:

V8 Engine
Node Runtime
Node APIs
C++ Bindings
libuv
Operating System
Hardware
The complete execution flow of JavaScript inside Node.js

Instead of memorizing Node.js...

we're going to understand it from the inside out.

Thank you for reading.

If this article helped you understand Node.js from first principles, stay tuned for Part 2, where we'll travel through every internal layer between your JavaScript code and the operating system.

DEV Community: Sudhanshu code

# From JavaScript to Node.js: Understanding What Really Happens Behind the Scenes (Part 4.3A.1)

What is Module Resolution?

Why Does Node Need a Resolution Algorithm?

Three Types of Modules

1. Core Modules

Why Are They Called Core Modules?

How Does Node Recognize a Core Module?

Is fs Written in JavaScript?

2. Local Modules

What Does ./ Mean?

Parent Directory

Going One Level Up

Going Multiple Levels Up

Relative Paths vs Absolute Paths

Relative Path

Absolute Path

How Does Node Decide?

Key Takeaways

Coming Next

From JavaScript to Node.js: Understanding What Really Happens Behind the Scenes (Part 4.2)

From JavaScript to Node.js: Understanding What Really Happens Behind the Scenes (Part 4.1)

From JavaScript to Node.js: Understanding What Really Happens Behind the Scenes (Part 3)

From JavaScript to Node.js: Understanding What Really Happens Behind the Scenes (Part 3)

Synchronous vs Asynchronous Node.js: What Really Happens Inside fs.readFile()?

What Does "Blocking" Actually Mean?

Understanding the Call Stack

Example

What Happens Inside readFileSync()?

Why Is It Called Synchronous?

Now Let's Look at readFile()

Step 1

Step 2

Step 3

Step 4

The Biggest Misconception

Why Doesn't V8 Read the File Directly?

Does libuv Read the File?

Why Is Node.js Fast?

Synchronous vs Asynchronous

Key Takeaways

Coming Next

From JavaScript to Node.js: Understanding What Really Happens Behind the Scenes (Part 2)

From JavaScript to Node.js: Understanding What Really Happens Behind the Scenes (Part 2)

What Actually Happens After You Run node app.js?

Step 1 — Your JavaScript File Is Just Text

Step 2 — The Operating System Starts Node.js

What Is a Process?

Step 3 — Node Initializes the Runtime

The Biggest Misconception About Node.js

Layer 1 — V8 Engine

What V8 Cannot Do

Layer 2 — Node APIs

Layer 3 — C++ Bindings

Layer 4 — libuv

So what is libuv?

Layer 5 — Operating System

Layer 6 — Hardware

Complete Flow

An Important Observation

Final Thoughts

Coming Next

From JavaScript to Node.js: Understanding What Really Happens Behind the Scenes (Part 1)

From JavaScript to Node.js: Understanding What Really Happens Behind the Scenes (Part 1)

Stop Memorizing Node.js. Start Understanding It.

Every Computer Speaks Only One Language

Why Programming Languages Exist

The Translator Between Humans and Computers

C Language

Java

JavaScript Is Different

JavaScript Inside the Browser

Does JavaScript Behave Differently Across Browsers?

The Problem Before Node.js

Why Browsers Restrict JavaScript

Then Came Ryan Dahl

So, What Is Node.js?

What Does Node.js Add?

Browser vs Node.js

A Different Way to Think About Node.js

Is `fs` Written in JavaScript?

What Does `./` Mean?

Synchronous vs Asynchronous Node.js: What Really Happens Inside `fs.readFile()`?

What Happens Inside `readFileSync()`?

Now Let's Look at `readFile()`

What Actually Happens After You Run `node app.js`?