Asynchronous JavaScript in Node

Node's superpower and its biggest source of beginner confusion are the same thing: asynchrony. The Node.js for Beginners series now explains why Node never blocks on I/O, how callbacks, promises and async/await express "come back later", and how the event loop keeps one thread serving many requests. This chapter is the mental model the HTTP chapters depend on.

Blocking vs non-blocking

A server that blocks for 200 ms per request can handle about 5 requests per second per thread. A non-blocking server hands the wait to the OS and processes everything else in the meantime — that asymmetry is the entire business case for Node.

Callbacks: the original style

Asynchronous Node APIs take a function to call when the work finishes. Their convention is error-first: the callback's first argument is an error (or null), the second is the result.

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

fs.readFile('notes.txt', 'utf8', (err, data) => {
  if (err) {
    console.error('could not read:', err.code);
    return;
  }
  console.log('file says:', data.trim());
});
console.log('this line runs first — the read is in flight');

Expected output:

this line runs first — the read is in flight
file says: remember to water the plants

Order matters: the last line prints first because readFile only schedules the work. Forgetting the if (err) guard is how "silent failure" bugs are born.

Promises and async/await

Promises wrap a future value; async/await lets you write that future as if it were ordinary sequential code. Modern Node APIs return promises — fs/promises, fetch, timers in node:timers/promises.

import { readFile } from 'node:fs/promises';

async function main() {
  const data = await readFile('notes.txt', 'utf8');
  console.log('file says:', data.trim());
  const upper = data.toUpperCase();
  console.log('shouty:', upper.trim());
}

main();
console.log('scheduled main() — runs after this line');

Expected output:

scheduled main() — runs after this line
file says: remember to water the plants
shouty: REMEMBER TO WATER THE PLANTS

• await pauses only the surrounding async function, never the thread.
• Errors become rejections — one try/catch covers every await in the block.
• Independent calls run in parallel with Promise.all([...]) instead of chained awaits.

Inside the event loop

When your stack empties, the loop drains its queues roughly in this order:

Microtasks — promise callbacks from await — are drained between every phase, which is why resolved promises run before any timer. You cannot see these phases directly, but knowing they exist explains the odd ordering you will occasionally observe: a setImmediate can beat a zero-delay setTimeout when the loop is already inside the check phase, and a promise callback always beats both.

Parallel, not concurrent-by-accident

const { readFile } = require('node:fs/promises');

async function readBoth() {
  const start = Date.now();
  // both reads are in flight at the same time
  const [a, b] = await Promise.all([
    readFile('a.txt', 'utf8'),
    readFile('b.txt', 'utf8'),
  ]);
  console.log('both in', Date.now() - start, 'ms');
  return [a, b];
}

readBoth();

Expected output: something like both in 3 ms — roughly the time of the slower read, not the sum. Sequential awaits would add the durations; Promise.all starts everything first.

Common mistakes

• Blocking the loop — a 500 ms synchronous loop or readFileSync inside a request stalls every client.
• Ignoring the error argument — error-first callbacks that skip the check swallow failures forever.
• Missing await — you get a promise object instead of the value; symptoms are undefined or [object Promise].
• Sequential awaits for independent work — chain latency unnecessarily; use Promise.all.
• Floats without handlers — an unhandled promise rejection prints a warning and, in current Node, crashes the process.

Practice checklist

1. Reproduce the callback example and deliberately remove the error guard to see the failure mode.
2. Rewrite a nested callback flow with async/await and a single try/catch.
3. Time three sequential setTimeouts versus Promise.all with node:timers/promises.
4. Trigger an unhandled rejection and observe Node's exit behaviour.
5. Add a synchronous busy-wait to a script and prove every later callback is delayed.

Asynchrony becomes concrete when the work is real: files on disk. Next: The File System Module.