What Does Asynchronous Mean in JS?

Asynchronous code does not run to completion before the next statement. The runtime schedules the work and moves on, and the work happens later, when the runtime gets back to it. That is what lets a page stay responsive while a network request is in flight.

console.log("1 - synchronous");

setTimeout(() => {
  console.log("3 - timeout callback");
}, 0);

Promise.resolve().then(() => {
  console.log("2 - promise callback");
});

console.log("4 - synchronous again");

The output order is the important part, and it surprises people. The synchronous lines run first, in order. Then the promise callback runs, and only after that does the timeout callback run, even though the timer was set up first. That is because the runtime drains all pending microtasks, which is where promise reactions live, before it moves on to the next macrotask such as a timer.

There are two families of asynchronous work in the language. Callback-based APIs, such as setTimeout and addEventListener, schedule a function to be called later. Promise-based APIs return an object you can attach handlers to, and those handlers run in the microtask queue, which means they get to run before the next timer or I/O callback.

One clarification worth making in an interview. Asynchronous does not mean parallel. JavaScript on the browser main thread and on a Node process runs your code on a single thread, so two pieces of your code never execute at the same time. What asynchronous buys you is the ability to wait for something slow without blocking the thread, and the runtime uses that time to handle input, paint the page, or serve other requests.

JavaScript is single-threaded by design. The language was built to run inside a browser, where the page and the user interface share one thread, and the original goal was that a script could not freeze the page while it ran. Adding threads to the language would have meant dealing with locks and shared memory in the middle of what was meant to be a simple scripting language, so the language stayed single-threaded and the runtime dealt with concurrency instead.

The event loop is the mechanism that makes that work. The runtime keeps a queue of tasks, such as timer callbacks, network completions and user events. When the current script finishes and the call stack is empty, the loop takes the next task and runs it. That is what gives the illusion of concurrency on one thread: while your code is waiting for a network response, the loop is free to run other tasks.

The consequence for a server is important. Node.js runs your request handlers on one thread, so a handler that does heavy synchronous work, like a huge regular expression match or a big JSON parse, blocks every other request. That is why the guidance is to keep the event loop free, to move heavy work to a worker thread or a separate process, and to prefer asynchronous I/O over synchronous file access.

Browsers add more than one thread to the picture. Rendering, compositing and JavaScript execution are separate threads, but they coordinate, and long-running JavaScript still blocks painting. That is the reason a long synchronous computation makes the page freeze even though the browser itself is multi-threaded.

The rule is short: synchronous code runs first, then the microtask queue is drained completely, and only then does the runtime take the next macrotask.

const order = [];

order.push("start");

setTimeout(() => order.push("timeout"), 0);

Promise.resolve()
  .then(() => order.push("promise 1"))
  .then(() => order.push("promise 2"));

queueMicrotask(() => order.push("microtask"));

order.push("end");

console.log(order.join(" -> "));
// start -> end -> promise 1 -> microtask -> promise 2 -> timeout

Two things in that output are worth explaining. The promise 2 callback is queued after promise 1 has run, because a chained then handler only gets scheduled when the promise it is attached to settles. And the microtask queued with the queueMicrotask call runs before promise 2, because it was already in the queue when promise 1 ran.

The general rule for the interview is that the microtask queue is drained completely between macrotasks. So if a timer callback queues more promise callbacks, those run before the next timer callback, and the queue keeps growing until it is empty. This is also why a promise chain that keeps queueing new microtasks can starve the event loop and make the page unresponsive, even though each individual step is asynchronous.

One more detail about timers. The delay you pass to setTimeout is a minimum, not a guarantee. If the runtime is busy, the callback waits longer. And in browsers a nested timer scheduled from inside a timer callback is clamped to about four milliseconds after five levels of nesting, which is a deliberate throttle that stops a chain of timers from spinning the CPU.