DEV Community

Sudhanshu code
Sudhanshu code

Posted on

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

#node #backend #javascript #programming

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
Enter fullscreen mode Exit fullscreen mode

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");
Enter fullscreen mode Exit fullscreen mode

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");
}
Enter fullscreen mode Exit fullscreen mode

Your CPU cannot execute this file directly.

It first goes through a compiler.

hello.c
      │
      ▼
 GCC Compiler
      │
      ▼
Machine Code (.exe)
      │
      ▼
CPU
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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");
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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(...)
Enter fullscreen mode Exit fullscreen mode

Nor this:

http.createServer(...)
Enter fullscreen mode Exit fullscreen mode

Nor this:

net.createConnection(...)
Enter fullscreen mode Exit fullscreen mode

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");
Enter fullscreen mode Exit fullscreen mode

but fails inside Node.js.

Likewise,

window.location
Enter fullscreen mode Exit fullscreen mode

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.

Top comments (0)