JavaScript for the Browser

The click that froze a page

You wire up a button. On click, it filters a list of 50,000 rows in a tight loop and re-renders. In testing it felt fine. In production a user clicks it and the entire page locks up, the spinner stops spinning, hover states stick, other buttons do nothing, even the browser's own tab feels dead. For two whole seconds nothing responds. Then it snaps back to life as if nothing happened.

Nothing crashed. No error in the console. The page wasn't "slow" in the network sense, the work was already done locally. So what happened? The answer is the single most important thing a frontend engineer can understand: JavaScript in the browser runs on one thread, and while your code runs, nothing else can. Not animation, not clicks, not paint. Once you internalize the runtime model, async stops being magic and bugs like this become obvious.

One chef, one thread

JavaScript in the browser is a single-threaded runtime: one call stack, doing one thing at a time. "Async" doesn't mean parallel, it means "do this later, when I'm free."

The cleanest mental model is a kitchen with exactly one chef. The chef can only do one task at a time. They have two notebooks. The first is a regular to-do list (tasks): "chop onions," "plate dish 4." The second is a priority list (microtasks): small urgent notes the chef promises to clear *before* starting the next to-do item.

The crucial rule: the chef finishes the current dish completely before looking at either list. They never abandon a half-plated dish to answer the door. That "run to completion" rule is exactly why a long task freezes everything, and why ordering between timers and promises is so precise.

The picture: how the event loop works

Here is the whole runtime in one diagram. Your synchronous code runs on the call stack. Anything async (a timer, a fetch, a click listener) is handed to Web APIs, which run outside the thread and, when done, drop a callback into a queue. The event loop is the part that, whenever the stack is empty, drains the microtask queue fully, then takes one macrotask, then repeats.

1. 1

   User clicks a button

   The browser's event system (a Web API) registers the click and queues your handler as a macrotask. Your currently-running code, if any, is not interrupted.

2. 2

   The stack empties

   Whatever was running finishes and returns. The call stack is now empty, the event loop's signal that it may pick up new work.

3. 3

   Microtasks drain first

   Before touching the click, the loop empties the entire microtask queue, every pending promise `.then`/`await` continuation runs to completion (and any microtasks they schedule run too).

4. 4

   One macrotask runs

   Now the loop takes exactly one task, your click handler, and pushes it onto the stack. It runs to completion, start to finish, uninterrupted.

5. 5

   Render gets a turn

   Only after the handler returns and microtasks are drained can the browser repaint. Then the loop comes back for the next macrotask.

Ordering: sync vs microtask vs macrotask

This is the table to memorize. Given this code, console.log("A"); setTimeout(() => console.log("D"), 0); Promise.resolve().then(() => console.log("C")); console.log("B");, the output is A, B, C, D. Synchronous lines run first, then all microtasks (the promise), then the macrotask (the timer), even though the timer was scheduled with 0.

Events, delegation, and async in real code

Two patterns cover most real frontend work: event delegation (one listener on a parent instead of one per child, leaning on event bubbling) and `async`/`await` for network calls. Here both are in a small, complete example, a list where clicking any item fetches its detail.

// ONE listener on the container, not one per <li>.
// Clicks on children bubble up to here, that's delegation.
const list = document.querySelector("#items");

list.addEventListener("click", async (event) => {
  // event.target is the actual clicked node; find the row it lives in.
  const item = event.target.closest("li[data-id]");
  if (!item) return; // clicked the gap between items, ignore.

  item.classList.add("loading");
  try {
    // await yields the thread back to the event loop while the
    // network request runs off-thread in a Web API.
    const res = await fetch(\`/api/items/\${item.dataset.id}\`);
    if (!res.ok) throw new Error(\`HTTP \${res.status}\`);
    const data = await res.json();

    // DOM manipulation: build a node, then attach it.
    const detail = document.createElement("p");
    detail.textContent = data.description;
    item.appendChild(detail);
  } catch (err) {
    item.textContent = "Failed to load, tap to retry.";
    console.error(err);
  } finally {
    item.classList.remove("loading");
  }
});

Why delegation wins: it works for rows added after the listener was attached (no rebinding), it uses one listener instead of thousands, and there's nothing to clean up per row. The await lines are where the thread is *handed back*, between them the browser is free to paint and handle other clicks. That's cooperative async on a single thread.

Why long tasks block paint

Now the frozen page makes sense. Rendering, style, layout, paint, is also work the one thread must do, scheduled between macrotasks. The browser wants to repaint roughly every 16ms (60fps). But it can only do that when the call stack is empty. While your filter-50,000-rows handler runs, the stack is never empty, so the loop never gets a turn, so no paint, no clicks, no animation. The thread is busy and there is only one.

A task that runs longer than ~50ms is officially a "long task", long enough that users perceive jank. The fix is never "make it async" by sprinkling promises (microtasks run on the *same* thread and still block paint). The fix is to break the work up, yield to the event loop between chunks (e.g. await scheduler.yield() or chunk across setTimeout/requestIdleCallback), or move the heavy computation off-thread entirely with a Web Worker, which is a genuinely separate thread.

Common mistakes that cost hours

1. Blocking the main thread. Heavy loops, giant JSON parses, or synchronous layout reads in a handler freeze everything. Chunk the work, defer it, or offload to a Web Worker.
2. Leaking listeners. Every addEventListener you never remove keeps its closure, and the DOM nodes it references, alive. In SPAs that re-mount components, this is the classic memory leak. Remove listeners on teardown, or use delegation so there's only one.
3. Not delegating. Attaching a listener to every item in a list is slower to set up, breaks for dynamically-added items, and multiplies cleanup. One listener on the parent + event.target.closest() is almost always better.
4. `await` inside a loop. for (const id of ids) { await fetch(id); } runs requests strictly one after another. If they're independent, fire them together with await Promise.all(ids.map(fetch)), same thread, but the waiting overlaps instead of stacking.

Takeaways

Where to go next

Once the runtime model clicks, the rest of frontend engineering layers cleanly on top. Two natural next reads: understanding what the browser does *after* your handler returns, and how to manage the data your handlers produce without re-introducing the chaos manual DOM updates create.

• How the Browser Renders a Page, what happens in that paint slot the event loop hands the browser: style, layout, and compositing.
• State Management in Frontend Apps, once DOM updates get complex, move state out of the DOM and let a framework re-render for you.
• Follow the full Frontend Engineer path to see where the runtime, rendering, and frameworks fit together.