Async JavaScript, Promises and the Event Loop

At 4+ years, an interviewer will not ask "what is a promise?". They show you ten lines of code and ask "what does this print, and why?". Then they ask you to write a concurrency limiter, cancel a request, or explain a stale search result. This lesson adds new angles to Async JS and the Event Loop and Browser Performance, Lesson 8. Every output below was run in Node 22. Every browser-only result was checked in Chromium 141.

Words used in this lesson

• The event loop is a loop that takes one piece of waiting work, runs it until it finishes, and then takes the next one. JavaScript has one thread, so this loop is the only way to "do many things".
• A task (also called a macrotask) is one item of work in the loop, such as a timer callback, a click handler or a network reply. A microtask is a tiny job that must run right after the current code ends, before the next task. Promise callbacks are microtasks. Difference in one line: a task is a whole turn, a microtask is a quick extra step at the end of a turn.
• A promise is an object that stands for a result that is not ready yet. It is pending first, then it becomes fulfilled (has a value) or rejected (has an error). Once settled, it never changes.
• A thenable is any object that has a .then method. Promises are thenables, but not every thenable is a promise.
• A callback is a function you pass to another function so it can call you back later.
• A race condition is a bug where the result depends on which of two async actions finishes first.
• Concurrency means several jobs are in progress at the same time (JavaScript does this by switching, not by running two lines at once). Parallelism means two things really run at the same moment (workers do this).
• Backoff means waiting longer between each retry. Jitter means adding a random part to that wait.

The event loop: browser vs Node

Both have the same core rule: one task, then all microtasks, then the next task. What differs is what lives around that rule.

The Node phases, in order: timers (due setTimeout/setInterval), pending callbacks, poll (wait for and run I/O callbacks), check (setImmediate callbacks), close callbacks. After each callback, Node empties the process.nextTick queue, then the microtask queue, and repeats until both are empty. (Before Node 11, this happened only between phases. Old blog posts still show the old behaviour.)

The rule about nextTick is the one people get wrong. process.nextTick(fn) adds fn to a queue that runs before the promise queue in a CommonJS file. In an ES module file, the module itself runs inside a promise job, so promise callbacks run first. The Node docs now mark process.nextTick as Legacy (since Node 22.7 and 20.18) and tell you to use queueMicrotask instead.

Puzzle 1: all the queues at once

// order.cjsconsole.log("A");setTimeout(() => console.log("timeout"), 0);setImmediate(() => console.log("immediate"));process.nextTick(() => console.log("nextTick"));Promise.resolve().then(() => console.log("promise"));queueMicrotask(() => console.log("microtask"));console.log("B");

Why is the last pair random? From the main script, Node starts the loop and checks the timer. If less than 1 ms has passed, the timer is not due yet, so setImmediate wins. If the machine was slow to start, the timer is due and wins. I ran it six times and saw both orders. Inside an I/O callback, the order is fixed: setImmediate always runs first, because the loop is in the poll phase and the check phase comes next.

const fs = require("fs");fs.readFile(__filename, () => {  setTimeout(() => console.log("timeout"), 0);  setImmediate(() => console.log("immediate"));  process.nextTick(() => console.log("nextTick"));  Promise.resolve().then(() => console.log("promise"));});// nextTick, promise, immediate, timeout  (always)

Puzzle 2: await and the queue

async function a1() { console.log("a1 start"); await a2(); console.log("a1 end"); }async function a2() { console.log("a2"); }console.log("script start");setTimeout(() => console.log("setTimeout"), 0);a1();new Promise((resolve) => { console.log("p1"); resolve(); }).then(() => console.log("p2"));console.log("script end");

Output: script start, a1 start, a2, p1, script end, a1 end, p2, setTimeout.

Reason: code before the first await runs synchronously, even inside an async function (a1 start, a2). The new Promise executor (the function you pass in) also runs synchronously (p1). await pauses a1 and puts its rest in the microtask queue, so a1 end comes before p2 because it was queued first. The timer is a task, so it comes last.

Puzzle 3: two chains take turns

Promise.resolve().then(() => console.log("A1")).then(() => console.log("A2")).then(() => console.log("A3"));Promise.resolve().then(() => console.log("B1")).then(() => console.log("B2"));(async () => { console.log("C0"); await null; console.log("C1"); await null; console.log("C2"); })();console.log("sync");

Output: C0 sync A1 B1 C1 A2 B2 C2 A3. Each .then or await is one "step" and each step goes to the back of the queue, so independent chains interleave one step at a time. Do not memorise results like this. Learn the method: write each callback on a numbered line for tick 1, tick 2, tick 3.

Puzzle 4: how many ticks does a return cost?

async function f1() { return 1; }async function f2() { return Promise.resolve(2); }async function f3() { return await Promise.resolve(3); }// compared with a plain chain t1 -> t2 -> t3 -> t4// result order: f1 t1 f3 t2 f2 t3 t4

Returning a plain value takes one tick. return await p takes two. Returning a promise from an async function takes three, because the engine needs extra steps to join the two promises. This is correct and standard, but you should never write code that depends on it. Interviewers ask it to see if you know "return a promise" is not free.

Browser-only angles

These were checked in Chromium 141.

• Rendering is a step, not a task. After a task and its microtasks, the browser may run requestAnimationFrame callbacks, then style, layout and paint. It does this only when a frame is due (about every 16.7 ms on a 60 Hz screen). Do not depend on the order of a timer and a rAF callback.
• Nested timers are slowed. In Chrome, a setTimeout(fn, 0) chain that is nested more than about five levels deep waits at least 4 ms per step. I measured 0.0 ms gaps for the first steps and 4.1 ms after that.
• A real click and el.click() differ. For a real user click on a button with two listeners, the log was R1, microtask from R1, R2: the browser runs microtasks between listeners. For button.click() called from code, it was L1, L2, microtask, because JavaScript was already on the stack. This surprises people who test with .click() and then see different results from real users.
• Hidden tabs are throttled. Timers in a background tab may fire only about once per second. Do not use timers to measure real time. Compare Date.now() or performance.now() instead.

Callbacks, promises, async/await

A callback is the oldest tool. It has two problems. First, nesting gets deep ("callback hell"). Second, you hand control to someone else's code, so you must trust they call you once, not twice, and not never. A promise fixes this: it settles once, and your .then is always called later, never synchronously.

async/await is a way to write promise code so it reads like normal top-to-bottom code. An async function is a function that always returns a promise. await pauses that function until a promise settles, and gives you the value or throws the error. It does not block the thread; other code keeps running while you wait.

Rules that matter in interviews:

• An async function never throws synchronously. A throw inside it becomes a rejected promise.
• A new Promise(executor) runs the executor at once, and a throw inside it becomes a rejection. But a throw inside a later callback (like a setTimeout inside it) is not converted. Wrap that in try/catch and call reject.
• resolve and reject work only once. After the first call, others are ignored.
• Promise.resolve(p) returns p itself if p is a native promise. new Promise(r => r(p)) makes a new promise that follows p.

Chaining rules: return vs throw

Each .then(onFulfilled, onRejected) returns a new promise. Its fate depends on what your handler does:

const bad = () => Promise.reject(new Error("boom"));// then(a, b): b handles the OLD promise. It does NOT catch errors thrown by a.Promise.resolve(1).then(  () => { throw new Error("ok-handler throws"); },  () => console.log("never runs")).catch((e) => console.log("caught:", e.message)); // caught: ok-handler throws// .catch() returns a promise, so the chain continues with the recovered valuePromise.reject(new Error("x")).catch(() => "recovered").then((v) => console.log(v)); // recovered

Difference in one line: .then(a, b) has b guard only the promise before it, but .then(a).catch(b) has b guard a too. Use .then().catch() in most cases.

.finally(fn) runs on both outcomes, gets no argument, and keeps the original result. The only way it changes the result is if fn throws (then the new error replaces it).

The try and return trap

async function a() { try { return fail(); }       catch { return "caught in a"; } }async function b() { try { return await fail(); } catch { return "caught in b"; } }// a() rejects! The catch never runs. b() returns "caught in b".

Without await, a returns the promise to the caller and leaves the try before the promise rejects. This is why many teams use return await inside try blocks.

Errors and unhandled rejections

An unhandled rejection happens when a promise is rejected and nobody has attached a handler by the time the microtask queue is empty.

I ran a rejected promise with a 50 ms late .catch. Node fired unhandledRejection first, then rejectionHandled when the catch arrived. In production, the right move is: catch where you can do something useful, and also add a global handler that logs and (in Node) lets the process exit so your process manager restarts it. A process in an unknown state is more dangerous than a restart. See Node.js & Express, lesson 6 for graceful shutdown.

Other facts that come up:

• If Promise.all rejects early, the other promises keep running (no cancel), and their later rejections do not raise a new unhandled rejection, because Promise.all attached handlers to all of them.
• A promise you create and await later can reject in the gap and trigger an unhandled rejection. Attach handlers early, or use Promise.all.
• Promise.try(fn) (run fn and always get a promise) is standard in Chrome 128, Firefox 134 and Safari 18.2, but not in Node 22 (I checked: typeof Promise.try is "undefined"). It arrives in Node 23+. In Node 22 use new Promise(r => r(fn())) or an async wrapper.

The combinators

A combinator is a function that takes many promises and gives back one.

I ran them on three promises: A (30 ms ok), B (10 ms fail), C (20 ms ok). all rejected with B. allSettled gave fulfilled, rejected, fulfilled. race rejected with B. any returned C (the first success). any over only failures gave AggregateError with an errors array of all reasons.

Promise.withResolvers() (ES2024) returns { promise, resolve, reject }, so you no longer need the let resolve; new Promise(r => resolve = r) trick. It works in Node 22, Chrome 119, Firefox 121 and Safari 17.4.

Sequential, parallel and limited concurrency

await sleep(50); await sleep(50);                 // sequential: ~100 msawait Promise.all([sleep(50), sleep(50)]);        // parallel:   ~50 msconst p1 = sleep(50), p2 = sleep(50);             // start early, await laterawait p1; await p2;                               // also ~50 ms

Start the work first, await later. But unlimited parallel is dangerous: 5,000 Promise.all requests can hit a rate limit, exhaust sockets or crash a database. You need a pool (a concurrency limit). This is a very common "implement it" question:

async function pool(tasks, limit) {  const results = new Array(tasks.length);  let next = 0, failed = false;  async function worker() {    while (!failed && next < tasks.length) {      const i = next++;                       // safe: no await between read and ++      try { results[i] = await tasks[i](); }      catch (e) { failed = true; throw e; }   // stop other workers taking new tasks    }  }  await Promise.all(Array.from({ length: Math.min(limit, tasks.length) }, worker));  return results;}

tasks is an array of functions that return promises (not promises, because a promise has already started). With 10 tasks and limit = 3, I measured a peak of exactly 3 running at once and results in the right order. Why is next++ safe? JavaScript never switches threads between those two lines. Without the failed flag, the version I first tested kept starting tasks after the first error: 3 had started when it rejected, and 6 by the end.

Other tools: p-limit and p-queue (small, popular packages) do the same with more features. For a stream of work, use a real queue, such as BullMQ (see the libraries lesson).

Async iteration

An async iterator is an object whose next() returns a promise. An async generator (async function*) is a function that can both await and yield. for await...of loops over them and waits for each item. (ES2018; Node 10+, Chrome 63, Firefox 57, Safari 12.)

async function* pages(fetchPage) {  let cursor = null;  do { const { items, next } = await fetchPage(cursor); yield* items; cursor = next; } while (cursor);}for await (const item of pages(getPage)) { /* one item at a time, next page fetched on demand */ }

What I verified:

• break inside for await calls the generator's finally block, so cleanup runs.
• for await also works on a normal array of promises and on Node streams (Readable is async iterable) and on web ReadableStream (Node 22, Chrome 124, Firefox 110).
• Values come out one at a time with backpressure: the producer waits for the consumer. That is why reading a huge file with for await (const chunk of stream) does not fill memory.
• Array.fromAsync(asyncIterable) collects them into an array (Node 22, Chrome 121, Firefox 115, Safari 16.4).

Cancellation, timeouts and retries

A promise cannot be cancelled. Promise.all rejecting does not stop the others. Cancel the work (the request, the timer) with an AbortController, an object that has a signal you pass to the work and an abort() method you call to say "stop".

fetch(url, { signal: AbortSignal.timeout(5000) });          // gives up after 5 sconst c = new AbortController();fetch(url, { signal: AbortSignal.any([c.signal, AbortSignal.timeout(5000)]) }); // user cancel OR timeout

What I observed in Node 22:

So catch blocks should check err.name, not just "an error". signal.throwIfAborted() lets your own code stop at checkpoints. AbortSignal.timeout counts active time only (MDN), and AbortSignal.any needs Node 20.3+, Chrome 116, Firefox 124, Safari 17.4.

Retry with backoff and jitter

async function retry(fn, { retries = 3, base = 100, max = 2000, signal, shouldRetry = () => true } = {}) {  for (let attempt = 0; ; attempt++) {    signal?.throwIfAborted();    try { return await fn(attempt); }    catch (err) {      if (attempt >= retries || !shouldRetry(err)) throw err;      const delay = Math.random() * Math.min(max, base * 2 ** attempt); // "full jitter"      await sleep(delay, signal);   // sleep that rejects when the signal aborts    }  }}

I tested three cases: a call that fails twice then succeeds (3 calls), a 400 error that was not retried because shouldRetry said no, and a retry loop stopped by an AbortSignal.timeout(60). Rules: retry only safe errors (network failure, 429, 503, and only GET or requests with an idempotency key), put a cap on attempts and on the delay, add jitter so a thousand clients do not retry at the same instant, and honour Retry-After.

Race conditions and stale responses

Search-as-you-type: the user types "re", "rea", "reac". Three requests start. The reply for "re" is slowest, so it arrives last and overwrites the right answer. I reproduced it: the naive code ended up showing results for re.

// Fix 1: only the latest request may writelet id = 0;async function search(q) { const mine = ++id; const r = await load(q); if (mine === id) show(r); }// Fix 2: abort the previous request (also saves bandwidth)let ctrl;async function search2(q) {  ctrl?.abort(); ctrl = new AbortController();  const r = await load(q, { signal: ctrl.signal });   // old call rejects with AbortError: ignore it  show(r);}

Both fixes showed results for reac. In React, the same idea is an effect cleanup (let ignore = false; return () => { ignore = true }), or use TanStack Query, which handles it (see React, lesson 4).

A second kind is check-then-act across an await. if (balance >= n) { await save(); balance -= n } called twice at once took 100 down to -60 in my test, because both checks passed before either update. Fix it with a database-level atomic update (UPDATE ... WHERE balance >= n) or, in one process, a promise chain that runs the calls one at a time. JavaScript is single-threaded, but await is a place where other code can run in between.

Async in loops

items.forEach(async (n) => { await work(n); });   // forEach does not wait: the next line runs firstfor (const n of items) { await work(n); }         // sequential, in orderawait Promise.all(items.map(async (n) => work(n))); // parallel, results in input order

I ran all of them. forEach printed "after forEach" before any item finished, and the items finished in time order (3, 2, 1), not list order. for...of ran one by one. map with Promise.all took the time of the slowest only and kept input order. Also: arr.map(async ...) gives an array of promises, and arr.filter(async n => n > 5) keeps everything, because a promise object is always truthy.

Top-level await, thenables and starvation

Top-level await lets you use await outside a function, but only in an ES module (ES2022; Node 14.8+, Chrome 89, Firefox 89, Safari 15). A .cjs file gives SyntaxError: await is only valid in async functions and the top level bodies of modules. A module that awaits makes modules that import it wait, but not unrelated siblings. I ran main importing a (waits 30 ms) and b: the order was a: start, b: start, a: done, main runs last. A slow top-level await slows start-up for everything that depends on it.

A thenable is called by await and Promise.resolve, but in a later microtask, not at once:

console.log("before");Promise.resolve({ then(res) { console.log("then() called"); res("T"); } }).then((v) => console.log("value", v));console.log("after");// before, after, then() called, value T

This is why returning a thenable from .then costs extra ticks, and why any object with a then method is dangerous: a plain data object with a then field gets treated as a promise.

Microtask starvation is when microtasks keep adding more microtasks, so the loop never reaches the next task. I queued 3,000,000 chained queueMicrotask calls and a 1 ms timer: the timer fired after about 480 ms. In a browser, this blocks painting and input too. Chaining setImmediate instead let the timer fire at once, because each immediate is a separate turn.

Workers, SharedArrayBuffer and Atomics

A Web Worker (Node: worker_threads) is a separate thread with its own event loop and memory. It cannot touch the DOM. You talk to it with postMessage, which copies the data (structured clone). You can transfer an ArrayBuffer instead: it moves, and the sender's copy becomes empty (I saw byteLength = 0 after a transfer).

SharedArrayBuffer is a block of memory that several threads can read and write. Two traps:

1. Browsers only give it to cross-origin isolated pages, which need the headers Cross-Origin-Opener-Policy: same-origin and Cross-Origin-Embedder-Policy: require-corp (or credentialless). In my plain test page, typeof SharedArrayBuffer was "undefined".
2. Shared memory brings real races. Four workers each did 100,000 v[0] = v[0] + 1. Expected: 400,000. I got 275,209. With Atomics.add(v, 0, 1) I got exactly 400,000.

Atomics is a set of operations (add, compareExchange, wait, notify) that happen as one unbreakable step. Atomics.wait blocks a thread, so it is not allowed on the browser main thread; use Atomics.waitAsync there. Use workers for CPU work (hashing, parsing, image work). Use plain async for waiting on I/O: workers do not make network calls faster.

fetch details

• HTTP errors do not reject. A 404 or 500 still resolves, with res.ok === false. Only a network failure, a CORS block or an abort rejects. Always check res.ok.
• A body can be read once. A second res.text() throws TypeError: Body is unusable. Use res.clone() first if you need two reads.
• The body is a stream. res.body is a ReadableStream, so you can read it chunk by chunk (for await (const chunk of res.body)). This is how streamed AI replies work.
• keepalive: true lets a request outlive the page (for analytics on pagehide). The total body of in-flight keepalive requests is limited to about 64 KiB: in Chromium 141, a 1 KiB body worked, and a 70 KiB body rejected. navigator.sendBeacon is the older tool for the same job.
• Timeouts are not built in. Use AbortSignal.timeout.
• fetch does not send cookies cross-origin unless credentials: "include", and sending a JSON body makes a CORS preflight. (See the browser lessons for CORS.)

Events: delegation, bubbling, capture, passive

Bubbling means an event starts at the clicked element (the target) and travels up through its parents. Capture is the trip down first. Order for a click: capture down, the target, then bubble up. Event delegation means putting one listener on a parent and using event.target.closest(selector) to find which child was clicked. It saves memory and works for items added later.

I tested a click on a span inside an li inside a div#list: the order was list capture, span (target), li bubble, list bubble. In the delegated handler, e.target was the SPAN, e.currentTarget was the list, and e.target.closest("li") found the row. That is the common bug: e.target may be a child of the element you wanted, so use closest.

• stopPropagation() stops the trip to other elements. stopImmediatePropagation() also stops other listeners on the same element. preventDefault() only cancels the browser default (a link, a form submit).
• Not every event bubbles: focus, blur, mouseenter do not (use focusin, focusout, mouseover).
• A passive listener ({ passive: true }) promises never to call preventDefault(). Then the browser scrolls without waiting for your code. If you call it anyway, it is ignored and Chrome logs an error (I saw Unable to preventDefault inside passive event listener invocation). wheel, touchstart and touchmove on window, document and body are passive by default.
• { once: true } removes the listener after one call. { signal } removes it when the signal aborts, so one abort() can clean up many listeners.

Yielding, idle time, debounce and throttle

To keep a page responsive, split long work and give the browser turns:

In Chromium, the continuation after await scheduler.yield() ran before a setTimeout(0) that was queued earlier. So write a helper: use scheduler.yield if it exists, else setTimeout. Do not use requestIdleCallback for work that must happen, because it may never run on a busy page.

Debounce means "wait until the events stop, then run once". Throttle means "run at most once every N ms while they continue". I fired an event every 30 ms for 300 ms with a 100 ms wait. Debounce ran once, at about 400 ms (after the last event). Throttle ran at about 0, 100, 200 and 300 ms.

function debounce(fn, wait) { let id; return (...a) => { clearTimeout(id); id = setTimeout(() => fn(...a), wait); }; }

Use debounce for search boxes and autosave. Use throttle for scroll, resize and drag. setInterval with a slow async callback overlaps (I counted 4 callbacks in flight). Use a setTimeout that schedules the next one after the work finishes.

Memory leaks from async code

A memory leak is memory your program keeps but can never use again. Async code leaks through things that stay alive and keep references:

• Timers and intervals never cleared. A running timer holds its callback, and everything the callback uses.
• Listeners added per request on something long-lived (a global emitter, window, a long AbortSignal) and never removed. Node warns after 10 listeners on one EventEmitter: I saw MaxListenersExceededWarning ... 11 x listeners added. Browsers give no warning.
• Promises that never settle, with a big closure attached, in a Map that only grows.
• Caches of promises with no limit or expiry.
• Components that set state after they unmount and keep references alive: cancel in the effect cleanup.
• In Node, call timer.unref() for background timers so they do not keep the process alive (a timer with unref() did not block exit in my test).

Find them with a heap snapshot: take one, use the app, take another, and compare what grew.

Interview questions

Key takeaways

• Order of work: synchronous code, then all microtasks, then the next task. Rendering fits between tasks in the browser.
• In Node: nextTick before promises in CommonJS, after them in ES modules. setTimeout(0) vs setImmediate is random from the main script and fixed inside I/O.
• await and .then each cost a queue step. Do not write code that depends on exact tick counts.
• .then(a, b) does not catch errors from a. Always return inside .then. Use return await inside try.
• Promises cannot be cancelled. Cancel the work with AbortSignal, and bound every external call with AbortSignal.timeout.
• Limit concurrency with a pool, retry only safe errors, and add jitter.
• Protect against stale responses by aborting or checking the latest request.
• fetch does not reject on HTTP errors. SharedArrayBuffer needs isolation and Atomics.

What's next

Practise by writing each puzzle from memory and predicting the output before you run it. Then read Async JS and the Event Loop for the step-by-step diagrams and Browser Performance for rendering.