The JavaScript Runtime, Event Loop, and Async Code

The short answer

JavaScript on a page usually runs one piece of main-thread code at a time. The surrounding browser can handle timers, network activity, and input while that code is not running. When an operation is ready to continue, the browser schedules more JavaScript. The event loop coordinates when tasks, microtasks, and rendering opportunities can happen.

This explains two common surprises: a zero-delay timer does not interrupt current code, and a fast network response can still leave the interface frozen if your processing code blocks the main thread.

JavaScript engine versus browser environment

The JavaScript engine evaluates the language: values, functions, expressions, and execution contexts. The browser supplies additional Web APIs such as the DOM, timers, and fetch. JavaScript itself does not contain a network stack or a document tree. Other environments, such as a server runtime, can run the language with a different set of APIs.

“JavaScript is single-threaded” is usually shorthand for one page's main JavaScript execution context. It does not mean the whole browser has one thread. Browsers perform work in other processes or threads and can also expose workers with separate execution contexts. The exact implementation is engine- and browser-dependent.

The call stack

When a function calls another function, the engine keeps track of the active execution contexts on a call stack. The called function runs and returns before the caller continues. Synchronous code in one task runs to completion before another task can take over that same execution context.MDN describes the stack and run-to-completion execution model.²

If a handler performs a large synchronous calculation, its stack remains busy. New clicks can be observed by the browser, but their main-thread handlers cannot run until that work yields or finishes.

Browser APIs

Calling setTimeout asks the browser to schedule a callback after a minimum delay. Calling fetch starts a request and returns a Promise. Registering an event listener tells the browser how to react to a later event. These calls do not mean the corresponding callback is running immediately.

Some work can proceed outside the current JavaScript stack, but asynchronous does not automatically mean your JavaScript calculations run in parallel. Once a callback starts on the main thread, it still uses that thread until it finishes or yields.

Tasks

A task is a unit of work selected by a browser event loop. Script execution, some event dispatches, and timer callbacks can arrive as tasks. The HTML Standard defines multiple task sources and selection rules; there is not one magical FIFO queue containing every possible event.The WHATWG HTML Standard defines event loops and task queues.¹

For day-to-day reasoning, it is enough to know that the currently running task must finish before a timer callback can run in a later task on that same loop.

Microtasks

Microtasks include Promise reactions. They run at microtask checkpoints after the current JavaScript work unwinds, before the browser moves on to another ordinary task. A callback registered with .then() does not run at the moment it is registered, even if the Promise is already fulfilled.MDN explains Promise reactions and microtask checkpoints.³

The browser keeps processing microtasks until the relevant queue is empty. Code that endlessly schedules more microtasks can therefore delay input handling or rendering. Microtasks are not a free shortcut around main-thread work.

The event loop

The browser's event loop is the scheduling model that selects runnable work, performs microtask checkpoints, and allows rendering updates when appropriate. It is not a loop application developers call manually. The diagram above deliberately compresses a much more detailed specification.

One useful rule follows: the next callback cannot interrupt a long-running synchronous function on the same main thread. A timer can expire or a response can arrive, but their handlers still wait for a chance to run.

Timers

setTimeout(fn, 0) means “schedule fn after at least the applicable delay,” not “run fn now.” Current code and queued microtasks can run first. Browsers also apply timing rules and may delay timers in background tabs or when the main thread is busy.MDN documents why timer callbacks can run later than requested.⁵

Do not use a timer's nominal delay as a guarantee of exact execution time or as proof that work happened in parallel.

Promises

A Promise represents an eventual result or failure. A .then() reaction is scheduled when the Promise settles; it does not make an operation itself asynchronous. Wrapping CPU-heavy synchronous work in Promise.resolve().then(...) merely moves that work into a microtask. It can still block the main thread when it runs.

Predict this browser-console output before revealing it:

console.log("first");
setTimeout(() => console.log("timer"), 0);
Promise.resolve().then(() => console.log("promise"));
console.log("last");

This is a controlled example without other scheduling work. Real applications have many task sources, but the stack/microtask/timer distinction remains useful.

async and await

An async function returns a Promise. At an await, that function's continuation pauses until the awaited value is ready, then resumes through Promise scheduling. The entire browser thread does not pause. Other eligible work can proceed while the function is suspended.MDN documents async function return values and await suspension.⁴

Code before the first await still runs synchronously when the function is called. Code after an await can also be expensive synchronous work once it resumes. await is a control-flow tool, not a performance guarantee.

Network requests

fetch() begins fetching and returns a Promise that resolves to a Response when response information is available. Reading and decoding the body may involve further asynchronous work. An HTTP error response such as 404 does not, by itself, reject the fetch Promise; code must inspect the response status.MDN documents Fetch's Promise and HTTP-error behavior.⁶

The APIs and JSON lesson explains request and response contracts. This lesson is about when a browser-side continuation can run after that exchange.

Rendering opportunities

After eligible work and a microtask checkpoint, a browser may update a visible document if a frame is needed and possible. It does not promise to paint between every two lines of code or after every task. The HTML Standard accounts for rendering opportunities and permits skipping unnecessary updates.The standard defines rendering updates within the event-loop model.¹

This is why setting a loading indicator and immediately running a long synchronous loop may leave the indicator unseen until the loop ends: JavaScript changed state, but the browser did not yet get a useful opportunity to paint.

Long-running JavaScript

Large parsing, sorting, or transformation work on the main thread can delay clicks, keyboard responses, and visual updates. Network time and CPU time are different boundaries. Chrome DevTools' Performance panel can show main-thread tasks and help locate the expensive function; its particular UI is Chrome-specific, while the main-thread concern is broader.Chrome documents main-thread traces and long-task markers.⁷

Reducing work, splitting work into smaller units, or moving suitable computation to a worker can help, depending on the task. None is a universal replacement for measuring what actually blocks the page.

Completion order and race conditions

Suppose a search interface sends a request for ca, then a request for cat. The cat response arrives first and displays useful results. If the older ca response arrives later and blindly updates the same UI, it replaces newer results with stale ones. Request order did not determine response order.

Possible defenses include canceling an obsolete fetch, tagging each request with an identity and ignoring older results, or checking that a response still matches the current query. Cancellation is one option, not a guarantee that no already-started work can complete.AbortController can abort an in-flight Fetch operation.⁸ The later data-fetching lesson will cover loading, errors, and caching more fully.

Common misconceptions

Debugging scenario

Why this matters when working with AI-generated code

Generated code can await fetch() correctly yet still overwrite newer search results with an older response. It can also put a large synchronous loop inside a Promise callback and call that “nonblocking.” Review the order in which requests start, finish, and update UI, and identify CPU work that occupies the main thread. Syntax that looks asynchronous is not proof of responsive behavior.

Knowledge check

What to learn next