Async JavaScript

A click handler that stalls the page and a setTimeout that fires later than its delay have the same root cause: one JavaScript thread that runs each job to completion while the host handles timers, networking, and events on its behalf. You follow work across that engine-to-host boundary, then place tasks, microtask checkpoints, and rendering opportunities on a single turn so ordering questions become predictable instead of surprising.

Every then, catch, and finally creates a new promise, and every await suspends the function and schedules its continuation as a microtask. Those two facts explain most confusing output orderings. You trace how values, thenables, and errors set the state of each link in a chain, where a rejection travels when nobody owns it, and how two async functions interleave line by line when they await the same kind of work.

Promise.all, allSettled, any, and race answer different questions about dependency and partial failure, and none of them cancel the operation that lost. That gap is where stale results overwrite current state and abandoned requests keep consuming resources. You design cooperative cancellation with AbortController and AbortSignal, compose signals for timeouts and competing sources, and clean up listeners, timers, and streams when work becomes obsolete.

A response body arriving in chunks and a thousand uploads started at once are both problems of pacing. You consume incremental sources with async generators, for-await-of, and ReadableStream readers while backpressure keeps producers honest, then replace unbounded fan-out with semaphore and sliding-window schedulers that limit in-flight work and still report ordered results and partial failures.