What Node.js actually is

A runtime, not a language: V8 + libuv + a standard library

Before you write a single line of server code, it’s worth knowing what “Node.js” actually is — because the mental model you form here will explain every quirk you hit later, from missing window to why one slow endpoint can freeze your entire API.

When people say “Node.js,” they mean three things bolted together into one program.

The first is V8 — the same engine Chrome uses to execute JavaScript. V8 takes your .js source, compiles it to machine code, and runs it fast. V8 alone, though, only understands JavaScript; it has no idea how to open a file or accept a network connection. The language spec has no fs, no http, no sockets.

The second piece fills that gap: libuv, a C library that gives Node an event loop plus asynchronous I/O (input/output — disk, network, timers). libuv is what lets one thread wait on thousands of connections at once instead of blocking on each. It also keeps a small thread pool in the background for the few operations the OS can’t do asynchronously (some filesystem and crypto work).

The third is Node’s standard library — the built-in modules that expose all of that to JavaScript: fs for files, http/net for servers and sockets, path, process for the running program itself, crypto, stream, and more. This is the part you actually require or import.

// No browser in sight — this is the standard library at work.
import { readFile } from "node:fs/promises";
import http from "node:http";

const html = await readFile("./index.html", "utf8"); // libuv reads the disk
http.createServer((req, res) => res.end(html))       // V8 runs your callback
    .listen(3000);
console.log(`pid ${process.pid} serving on :3000`);   // process = this program

Why does this combination exist at all? Because before Node, JavaScript was trapped in the browser and servers were written in PHP, Python, Ruby, or Java. Node let teams write one language across the whole stack — frontend and backend — and tap the enormous npm package ecosystem. That single decision is most of why Node took over backend tooling.

One thread, an event loop, and non-blocking I/O

Here is the idea that makes Node feel strange coming from other backends: your JavaScript runs on a single thread. There is no thread-per-request. So how does one thread serve thousands of clients?

The trick is non-blocking I/O. When your code asks to read a file or query a database, Node does not sit and wait for the answer. It hands the request to libuv (which uses the OS or the thread pool), registers a callback, and immediately moves on to other work. When the data is ready, libuv puts the callback on a queue, and the event loop — a loop that runs forever, pulling finished work off queues and executing the callbacks — runs it. The one thread is almost never idle and almost never blocked, so it can interleave thousands of in-flight operations.

The catch is the flip side. If you give that single thread CPU-bound work — a tight loop hashing a million passwords, resizing a huge image, parsing a giant JSON synchronously — there is no one else to take requests while it grinds. The event loop is blocked. Every other client waits. I/O is offloaded; computation is not.

Where Node shines, and where it doesn’t

This architecture is not better or worse than thread-per-request backends — it’s shaped for a particular kind of work. Knowing the shape tells you when to reach for Node.

Node is excellent at I/O-bound work, because that is exactly what non-blocking I/O and the event loop are built for: HTTP APIs and microservices that mostly wait on databases and other services, real-time systems (chat, live dashboards) over WebSockets, and developer tooling (bundlers, linters, CLIs) where reading and writing files dominates. It is poor at heavy CPU-bound compute — video transcoding, large numeric simulations, big synchronous crypto — because that work blocks the one thread. The escape hatches are real but deliberate: worker_threads to move computation off the main thread, or simply reaching for a language better suited to the number-crunching.

The ecosystem is the other half of the picture. npm is Node’s package registry and installer — the largest software registry in the world. On top of it sit the frameworks you’ll meet next: Express and Fastify for HTTP servers, NestJS for structured, opinionated backends. Treat those names as a map, not today’s homework.