Node.js Fundamentals

Node.js is not a language and not a framework. It is a runtime: a C++ program that embeds a JavaScript engine and gives it access to the outside world. On its own, JavaScript can add numbers, build objects and call functions, but it has no idea what a file, a socket or a clock is. Node supplies those.

It is built from four layers:

• V8 — Google's JavaScript engine (the one in Chrome). It parses and compiles your code, runs it on the call stack, owns the heap and does garbage collection. V8 knows nothing about files, networks or timers.
• libuv — a C library that provides the event loop, cross-platform asynchronous I/O (epoll on Linux, kqueue on macOS, IOCP on Windows), timers, and a small thread pool for work the OS can't do asynchronously.
• The C++ bindings — Node's own glue code. They expose libuv, OpenSSL (crypto), zlib (compression), llhttp (HTTP parsing) and c-ares (DNS) to JavaScript as native functions.
• Node's JavaScript library — the node:fs, node:http, node:events… modules you require. They are written in JavaScript and call down into the bindings.

A mental model: V8 is a chef who can only cook; libuv is the kitchen manager with a pager, a phone and a few helpers. The chef never waits by the oven or at the door. They hand the waiting to the manager, keep cooking, and the manager hands them a ticket when something is ready. The bindings are the intercom between them.

You can see the parts and their versions in any Node:

const v = process.versions;
console.log({ node: v.node, v8: v.v8, uv: v.uv, openssl: v.openssl, zlib: v.zlib, llhttp: v.llhttp, ares: v.ares });
// {
//   node: '26.7.0',
//   v8: '14.6.202.34-node.28',
//   uv: '1.52.1',
//   openssl: '3.6.3',
//   zlib: '1.2.12',
//   llhttp: '9.4.3',
//   ares: '1.34.8'
// }

const fs = require('node:fs');

fs.readFile(__filename, () => {
  console.log(new Error('inside the readFile callback').stack);
});
setTimeout(() => console.log(new Error('inside a timer').stack), 5);
setImmediate(() => console.log(new Error('inside setImmediate').stack));

// Error: inside setImmediate
//     at Immediate._onImmediate (…/stack.cjs:7:32)
//     at process.processImmediate (node:internal/timers:574:21)
// Error: inside the readFile callback
//     at …/stack.cjs:4:15
//     at FSReqCallback.readFileAfterClose [as oncomplete] (node:internal/fs/read/context:96:3)
// Error: inside a timer
//     at Timeout._onTimeout (…/stack.cjs:6:30)
//     at listOnTimeout (node:internal/timers:685:17)
//     at process.processTimers (node:internal/timers:618:7)

When people say "Node is single-threaded", they mean something narrower than it sounds: your JavaScript runs on one main thread, one piece at a time. There is one call stack, one heap for your objects, and no two of your callbacks ever run simultaneously. That is why you never need locks around a shared variable in normal Node code.

It does not mean the Node process has one thread. The process has several: V8 runs helper threads, and libuv starts a thread pool the first time something needs it. Those threads never run your JavaScript; they do native work and report back to the main thread through the event loop.

const { execFileSync } = require('node:child_process');
const crypto = require('node:crypto');

// macOS: `ps -M <pid>` prints one line per thread (plus a header line).
const count = () => execFileSync('ps', ['-M', String(process.pid)]).toString().trim().split('\n').length - 1;

console.log('threads at startup:', count());
crypto.pbkdf2('x', 'y', 1, 32, 'sha256', () => {
  console.log('threads after first thread-pool job:', count());
});

// threads at startup: 7
// threads after first thread-pool job: 11

const t0 = Date.now();
setTimeout(() => console.log(`timer due at 0 ms ran at ${Date.now() - t0} ms`), 0);

const end = Date.now() + 100;
while (Date.now() < end) {} // 100 ms of synchronous work
console.log(`loop finished at ${Date.now() - t0} ms`);

// loop finished at 100 ms
// timer due at 0 ms ran at 101 ms

From my notes: the REPL (Read-Eval-Print-Loop) is an interactive shell that ships with every Node installation. It reads a line of JavaScript, evaluates it, prints the result and loops back for more, until you exit. You start it by running node with no arguments.

It is the fastest way to answer "what does this actually return?" — the exact behaviour of Buffer.from, a regex, a date conversion — without creating a file. Here is a real session, typed into a terminal on Node 26:

Welcome to Node.js v26.7.0.
Type ".help" for more information.
> 1 + 2
3
> _ * 10
30
> await new Promise(r => setTimeout(() => r("done"), 50))
'done'
> null.x
Uncaught TypeError: Cannot read properties of null (reading 'x')
> _error.message
"Cannot read properties of null (reading 'x')"
> os.cpus().length
18
> .editor
// Entering editor mode (Ctrl+D to finish, Ctrl+C to cancel)
function twice(n) {
  return n * 2;
}
twice(21)

42
> .exit

Every piece of work is mostly waiting or mostly computing, and Node treats the two very differently.

• I/O-bound work is dominated by waiting for something outside the process: a database query, an HTTP call, Redis, a file read, a message from a socket. The CPU is idle while you wait.
• CPU-bound work is dominated by computation on your thread: parsing a huge JSON payload, resizing an image, hashing passwords synchronously, sorting a million rows, running a report.

The distinction matters because Node's model is built around giving the thread away during waits. While one request waits for the database, the same thread runs other requests' code. That only works if the waits are long and the computations are short. A CPU-bound task never gives the thread away, so everything else waits for it.

The difference shows up immediately when you try to "parallelise" both kinds with Promise.all:

const { setTimeout: sleep } = require('node:timers/promises');

function busy(ms) {               // CPU-bound: keeps the thread computing
  const end = Date.now() + ms;
  while (Date.now() < end) {}
}

async function main() {
  let t = Date.now();
  await Promise.all([sleep(200), sleep(200), sleep(200)]); // three "DB calls"
  console.log(`3 x 200 ms of waiting:   ${Date.now() - t} ms`);

  t = Date.now();
  await Promise.all([1, 2, 3].map(async () => busy(200)));  // three "calculations"
  console.log(`3 x 200 ms of computing: ${Date.now() - t} ms`);
}
main();

// 3 x 200 ms of waiting:   201 ms
// 3 x 200 ms of computing: 600 ms

The two words are often used interchangeably, but interviewers expect you to separate them:

• Concurrency is about structure: several tasks are in progress during overlapping periods of time. They take turns. One worker can be concurrent.
• Parallelism is about execution: several computations are running at the same instant, on different CPU cores. You need more than one worker.

A coffee-shop analogy: one barista who starts the espresso, steams milk while it pours, and takes the next order during the steam is concurrent. Three baristas each making a drink at the same time is parallel. Node's main thread is the single barista — very good at juggling orders that involve waiting on machines.

My notes put it in capitals: "Node.js is good at concurrent I/O." Here is what that looks like — two requests in progress at once, on one thread:

const { setTimeout: sleep } = require('node:timers/promises');
const t0 = Date.now();
const log = (msg) => console.log(`${String(Date.now() - t0).padStart(3)} ms  ${msg}`);

async function handle(name, dbMs) {
  log(`${name}: start, query DB`);
  await sleep(dbMs);             // waiting: the thread is free
  log(`${name}: got rows, send response`);
}

handle('A', 100);
handle('B', 50);
log('both started');

//   0 ms  A: start, query DB
//   1 ms  B: start, query DB
//   1 ms  both started
//  52 ms  B: got rows, send response
// 102 ms  A: got rows, send response

const { Worker } = require('node:worker_threads');

// Each worker is a separate JS thread (its own V8 isolate and event loop).
const code = `
  const end = Date.now() + 200;
  while (Date.now() < end) {}   // 200 ms of pure CPU
`;
const runInWorker = () =>
  new Promise((resolve, reject) => {
    new Worker(code, { eval: true }).once('exit', resolve).once('error', reject);
  });

const t = Date.now();
Promise.all([runInWorker(), runInWorker(), runInWorker()]).then(() => {
  console.log(`3 x 200 ms of computing in 3 workers: ${Date.now() - t} ms`);
});

// 3 x 200 ms of computing in 3 workers: 213 ms

Most of Node's I/O functions come in two flavours. fs.readFileSync is synchronous: it blocks the calling thread until the data is ready and returns it. fs.readFile is asynchronous: it starts the operation, returns undefined immediately, and calls your callback later with the result. (fs/promises has a third flavour, await readFile(...), which is the asynchronous version returning a promise.)

The example from my notes, extended to show the order things happen in:

const fs = require('node:fs');

console.log('1. before readFileSync');
const text = fs.readFileSync(__filename, 'utf8');      // thread waits here
console.log('2. readFileSync returned', text.length, 'chars');

fs.readFile(__filename, 'utf8', (err, data) => {        // thread moves on
  if (err) throw err;
  console.log('4. readFile callback', data.length, 'chars');
});
console.log('3. after readFile call');

// 1. before readFileSync
// 2. readFileSync returned 537 chars
// 3. after readFile call
// 4. readFile callback 537 chars

const fs = require('node:fs');
const path = process.argv[2];
const t0 = Date.now();
setTimeout(() => console.log(`timer due at 10 ms fired at ${Date.now() - t0} ms`), 10);

if (process.argv[3] === 'sync') {
  const buf = fs.readFileSync(path);
  console.log(`readFileSync: ${buf.length} bytes at ${Date.now() - t0} ms`);
} else {
  fs.readFile(path, (err, buf) => {
    if (err) throw err;
    console.log(`readFile:     ${buf.length} bytes at ${Date.now() - t0} ms`);
  });
}

// $ node block-timer.cjs big.bin sync
// readFileSync: 536870912 bytes at 47 ms
// timer due at 10 ms fired at 49 ms
//
// $ node block-timer.cjs big.bin async
// timer due at 10 ms fired at 10 ms
// readFile:     536870912 bytes at 62 ms

The classic comparison is about how each one serves many requests at once.

A traditional Java server (Tomcat/Spring MVC, the servlet model) is thread-per-request: each request gets a thread from a pool, and that thread runs the handler from start to finish. When the handler calls the database, the thread blocks and sits there waiting. To serve 1,000 concurrent slow requests you need ~1,000 threads, and each platform thread costs memory for its stack and time for the OS to schedule. The upside: blocking code is simple to write and read, and CPU-heavy requests run in parallel on all cores for free.

Node is event-loop: one thread runs every request's JavaScript, and nothing blocks — a database call registers a callback (or an await) and the thread moves on to the next request. Thousands of concurrent waits cost a few objects each, not a thread each. The downside: one CPU-heavy request stalls everyone, and a single process uses one core for JavaScript.

The modern twist is that the gap has narrowed from both sides:

• Java has event loops too. Netty, Vert.x and Spring WebFlux are non-blocking, event-loop frameworks — the same model as Node, with the same "don't block the loop" rule.
• Java 21's virtual threads (Project Loom) make thread-per-request cheap: a virtual thread that blocks on I/O is unmounted from its carrier OS thread, so you can have hundreds of thousands of them. You keep simple blocking code and get Node-like scalability for I/O.
• Node can use all cores with worker threads for CPU work and the cluster module or multiple containers for throughput.

So the honest answer to "which is better?" is about fit: Node shines for I/O-heavy services, streaming and real-time connections, and teams already in TypeScript; Java (especially with virtual threads) shines for CPU-heavy or highly concurrent compute, very large domains that benefit from the JVM's tooling, and workloads that need true shared-memory multithreading.