# What is Node.js? JavaScript on the Server Explained

# 01 What Node.js Is

When you write console.log("hello") that is JavaScript — the programming language. But something has to **execute** that code. In the browser, that something is the browser's built-in engine.

Node.js is a **runtime environment** that can run JavaScript directly on your machine or server, with no browser involved.

> **Node.js** is a runtime environment built on Chrome's **V8 JavaScript engine**. It lets you run JavaScript code outside the browser — on a server, your local machine, or any system. It was created by Ryan Dahl in 2009.

# 02 Why JavaScript was originally broswer only ?

Initially, JavaScript could only run inside browsers because it needed a runtime environment like Chrome or Firefox.

JavaScript was created in 1995 by Brendan Eich at Netscape. Its only job was to make HTML pages interactive — form validation, button clicks, dropdown menus. Because it ran inside a browser tab on a visitor's machine, giving it access to the local file system or network would have been a serious security risk.

Browsers provided:

*   Memory management
    
*   Execution environment
    
*   APIs (like DOM)
    

Without a runtime, JavaScript couldn’t run independently.

JavaScript in the browser *cannot*:

1.  Read or write files on your machine (fs.readFile doesn't exist in browser JS).
    
2.  Open raw TCP/UDP socket connections.
    

They are deliberate restrictions. Something that reads databases, writes files, handles HTTP requests — you had to switch to a different language entirely: PHP, Java, Python, Ruby.

> JavaScript as a language is perfectly capable of doing backend work — it just needed a new environment without those restrictions. That environment is Node.js.  

# 03 How Node.js made JavaScript run on servers

Node.js introduced a runtime environment that allows JavaScript to run on servers.

Ryan Dahl's idea was simple: take Chrome's V8 engine (which was open-source), run it as a standalone C++ program, and wrap it with APIs that talk directly to the operating system — file system, network, timers, processes.

The result is a layered stack. Your JavaScript code sits at the top. Below it, Node.js provides built-in modules. Below those, V8 executes the JS. And at the very bottom, a library called **libuv** handles all the async I/O — file reads, network calls, timers — without blocking the main thread.

![](https://cdn.hashnode.com/uploads/covers/696f304bc3ffcbb856137e02/c348b625-7a29-4132-bd52-6aa1ba384411.png align="center")

The key takeaway: **libuv is what makes Node.js asynchronous**. When your code calls `fs.readFile()`, Node.js hands that task to libuv, which delegates it to the OS. The main thread continues running other code. When the file is ready, libuv notifies the event loop, which then runs your callback. This is why Node.js can handle many operations without spawning multiple threads.

#   
04 The V8 Engine

The V8 engine is the core of Node.js. V8 is an open-source JavaScript engine built by Google, written in C++. Originally built for Chrome, it was designed to be fast. Its primary job: take your JavaScript source code and convert it into native machine code that your CPU can directly execute — not by interpreting it line-by-line, but by compiling it **Just-In-Time (JIT)**.

```javascript
V8 = Converts JS → Machine Code
```

> What JIT means
> 
> Traditional interpreters read code line-by-line at runtime — slow. Traditional compilers compile everything upfront before running — inflexible. JIT does both: it compiles code to machine instructions at runtime, and it also **optimizes the hot paths** (functions that run often). This is why JS performance has gotten dramatically better over the years.

V8 also manages **memory** — allocating objects when you create them, and garbage-collecting them when they're no longer referenced. You don't manage memory manually in JavaScript; V8 does it for you.

When Node.js was built, Ryan Dahl simply took V8, ran it outside the browser as a standalone process, and wired up new APIs around it. V8 itself didn't change — what changed was the environment around it.

## 05 Event-Driven Architecture

### **Single-threaded, non-blocking— how it actually works**

Most backend servers (Java, PHP historically) follow a **thread-per-request model**: each incoming request gets its own thread. Threads have overhead — memory, context-switching. At scale, you end up with hundreds of threads sitting idle, just waiting for a database response.

Node.js takes a completely different approach: **one thread, event loop, non-blocking I/O**. Instead of threads waiting for I/O, Node.js registers a callback and moves on. The event loop continuously checks: "is any pending async operation done?" If yes, it picks up that callback and runs it.

![](https://cdn.hashnode.com/uploads/covers/696f304bc3ffcbb856137e02/d877aa03-95cf-4623-abff-2ae0de5dc9f9.png align="center")

Here's that exact flow written in code:

```javascript
const fs = require('fs');

// Step 1: readFile is called. Node registers the callback and passes
// the actual file-read work to libuv (OS). Stack is now free.
fs.readFile('data.json', 'utf8', (err, data) => {
  // Step 3: file is ready. Event loop pushed this callback to the stack.
  if (err) throw err;
  console.log('File contents:', data);
});

// Step 2: This runs IMMEDIATELY — doesn't wait for the file read.
// The call stack is free to handle more work while libuv reads the file.
console.log('Registered the readFile. Moving on.');
```

```javascript
// Output order — this surprises most people the first time:
// > Registered the readFile. Moving on.
// > File contents: { ... }   ← runs after, when OS is done
```

> The one limitation
> 
> Because Node.js is single-threaded, **CPU-heavy synchronous work blocks everything**. If you run a loop that takes 5 seconds, no other requests are handled during that time. This is why Node.js is excellent for I/O-heavy work (APIs, databases, file operations) but not suited for CPU-intensive tasks like video encoding, image resizing, or machine learning inference — use Python or Go for those.

## 06 Real-World Use Cases

## **Where Node.js is actually used — and why**

Node.js is widely used in:

1.  **REST APIs(Building APIs)** — Express.js handles thousands of requests/sec efficiently. Most backends you interact with daily run on this.
    
2.  **Real-time Apps** — Chat apps, live notifications, collaborative tools like Figma. Node keeps thousands of WebSocket connections open without spawning threads.
    
3.  **Developer Tooling** — Webpack, Vite, ESLint, Prettier, Jest. Every JS tool you use is a Node.js program running on your machine.
    
4.  **Microservices —** Node starts in under 100ms and uses ~30MB RAM idle. Perfect for containerized services.
    
5.  **Streaming** — Reading, transforming, writing large files without loading everything into memory at once.
    
6.  **BFF Pattern** — A Node.js layer sits between your frontend and downstream services, shaping and combining data.
    

## **Node.js vs Traditional Backend Runtimes**

| **Factor** | **Node.js** | **PHP / Java (traditional)** |
| --- | --- | --- |
| **Language** | JavaScript — same as frontend | Separate language to learn |
| **Concurrency model** | Event loop · non-blocking I/O | Thread-per-request |
| **Memory per request** | Low — no thread per request | Higher — each thread uses RAM |
| **I/O-heavy workloads** | Excellent | Good but thread overhead adds up |
| **CPU-heavy workloads** | Weak — blocks the event loop | Better — true multithreading |
| **Package ecosystem** | npm — largest in the world | Large but more fragmented |
| **Shared code (frontend/backend)** | Yes — same JS types, utils, validation | No — rewrite logic twice |

### **Quick Reference Summary**

**Node.js** = V8 engine + libuv + built-in OS APIs, running JavaScript outside the browser.  
**V8** compiles and executes your JS. **libuv** handles async I/O without blocking.  
**The event loop** coordinates it all on a single thread.  
Best for: **APIs, real-time apps, tooling, streaming, microservices.**  
Not for: **CPU-intensive computation.**