Browser, DOM & Events

The browser builds a page by reading the HTML from top to bottom and turning each tag into a DOM node as it goes. When that parser meets a classic <script>, it has to stop and run the script before it parses anything else. The reason is historical but still binding: a script is allowed to change what comes next — it can call document.write() to inject more markup, or read and modify the elements parsed so far — so the parser can't safely carry on until the script has been downloaded and executed.

That costs you twice. First, the user stares at a blank or half-built page while the script travels over the network; a large script in the <head> delays everything below it. Second, the script can only see elements above it, so document.getElementById for anything further down returns null. The old workaround was to put scripts at the end of <body>. defer, async and modules fix it properly by letting the download happen in parallel with parsing and only differing in when the script runs.

A mental model: the parser is someone reading a book aloud. A plain script is a phone call they must make and finish before reading the next sentence. async is a parcel someone else fetches — the reader is interrupted the moment it arrives, whatever page they're on. defer is a stack of notes to read, in order, once the last chapter is done.

<script src="app.js"></script>                <!-- blocks parsing -->
<script src="app.js" defer></script>          <!-- runs after parsing, in order -->
<script src="analytics.js" async></script>    <!-- runs as soon as it arrives, any order -->
<script type="module" src="main.js"></script> <!-- deferred by default + import/export -->

<head>
  <script>
    const btn = document.getElementById("save");
    btn.addEventListener("click", save); // TypeError — btn is null
  </script>
</head>
<body>
  <button id="save">Save</button>
</body>

An event is never delivered to just one element. When you click a button, you have also clicked the <div> around it, the <body>, and the whole document. The DOM models this by sending one event object on a round trip: down from window to the element that was clicked, then back up again. The route — the event path — is worked out once when the event starts, from the target's chain of ancestors, so moving or removing elements mid-event doesn't change who it visits.

A mental model: a lift that goes down a building to one floor and then back up to the roof. Listeners are people waiting on each floor. A few of them want to catch the lift on the way down (capture); most wait for it on the way up (bubble).

When you click an element, the event travels in three phases:

1. Capturing — from window down through each ancestor to the target.
2. Target — at the element that was clicked.
3. Bubbling — back up from the target through each ancestor to window.

You can read the current phase from e.eventPhase: 1 capturing, 2 at target, 3 bubbling.

addEventListener listens in the bubbling phase by default. Pass { capture: true } (or true) to listen on the way down instead.

<div id="outer">
  <button id="inner">Click</button>
</div>

const outer = document.getElementById("outer");
const inner = document.getElementById("inner");

outer.addEventListener("click", () => console.log("outer capture"), { capture: true });
outer.addEventListener("click", () => console.log("outer bubble"));
inner.addEventListener("click", () => console.log("inner"));

// Clicking the button logs:
// outer capture → inner → outer bubble

Because one event object visits many elements, it needs two "where" properties. target answers where did this start? and is set once, before the trip begins. currentTarget answers which element am I being handled at right now? and the browser updates it before each listener runs.

Think of a parcel moving through post offices: target is the address it was sent from and never changes; currentTarget is the office it is sitting in right now.

• event.target — the element where the event started (what was actually clicked).
• event.currentTarget — the element whose listener is running right now (where you attached it). Inside a regular-function handler, this === event.currentTarget.

document.querySelector("ul").addEventListener("click", (e) => {
  console.log(e.target.tagName);        // "LI" (or a <span> inside it!)
  console.log(e.currentTarget.tagName); // "UL" — always the element with the listener
});

list.addEventListener("click", function (e) {
  console.log(this === e.currentTarget); // true — a regular function's `this` is the element
  setTimeout(() => {
    console.log(e.target);        // still the clicked element
    console.log(e.currentTarget); // null — the dispatch has finished
  }, 0);
});

These are two independent switches on the event object. Propagation is about which other listeners get to see the event. The default action is what the browser itself does once the listeners are done: follow a link, submit a form, type the character for a keydown, open the context menu, scroll on a wheel or touch. The browser runs all the listeners first, then checks e.defaultPrevented to decide whether to do its default — which is why preventDefault() has to be called synchronously inside the handler, not after an await. (Checkboxes are a slight exception: the browser toggles the box before your listener runs and toggles it back if you cancel, so inside a click handler checked already shows the new value.)

A mental model: stopPropagation() says "nobody else needs to hear about this"; preventDefault() says "browser, don't do your usual thing". Neither one implies the other.

These do completely different things:

// Handle a form with JavaScript instead of reloading the page
form.addEventListener("submit", (e) => {
  e.preventDefault();
  const data = new FormData(form);
  fetch("/api/signup", { method: "POST", body: data });
});

// A click inside a modal shouldn't reach the backdrop's "close" handler
modal.addEventListener("click", (e) => e.stopPropagation());
backdrop.addEventListener("click", closeModal);

backdrop.addEventListener("click", (e) => {
  if (e.target === backdrop) closeModal(); // only clicks that started on the backdrop itself
});

button.addEventListener("click", (e) => {
  console.log("first");
  e.stopImmediatePropagation();
});
button.addEventListener("click", () => console.log("second"));     // never runs
document.addEventListener("click", () => console.log("document")); // never runs
// Clicking the button logs only: first

Instead of attaching a listener to every child, attach one listener to a common parent and use event.target to work out which child was clicked. This works because of bubbling.

It works because every click on anything inside the list has to bubble through the list on its way up. The parent sees every one of those clicks and can ask "which of my children did this come from?". It's a receptionist at the front desk instead of a guard at every door: one person, and new rooms are covered the moment they're built.

<ul id="item-list">
  <li data-id="1">Item 1 <button class="delete">✕</button></li>
  <li data-id="2">Item 2 <button class="delete">✕</button></li>
  <li data-id="3">Item 3 <button class="delete">✕</button></li>
</ul>

document.getElementById("item-list").addEventListener("click", (event) => {
  // closest() handles clicks on nested elements inside the <li>
  const deleteBtn = event.target.closest(".delete");
  if (deleteBtn) {
    deleteBtn.closest("li").remove();
    return;
  }

  const li = event.target.closest("li");
  if (li && event.currentTarget.contains(li)) {
    console.log("List item clicked:", li.dataset.id);
  }
});

React uses event delegation for you. Even though you write onClick on individual elements, React attaches one native listener per event type (and phase) to the root container — the element you pass to createRoot; before React 17 it was document. It does this once, up front, for nearly every event it supports; a few that don't bubble natively (media events such as onPlay, and onScroll since React 17) are attached to the element itself.

When an event bubbles up to the root, React works out which component rendered the target from its internal fiber tree, then calls your handlers in the right order with a SyntheticEvent — a cross-browser wrapper around the native event with the same interface (e.target, e.preventDefault(), e.stopPropagation()). The original is still there as e.nativeEvent.

function List({ items, onSelect }) {
  // No real listener is attached to each <li> — React delegates to the root
  return (
    <ul>
      {items.map((item) => (
        <li key={item.id} onClick={() => onSelect(item.id)}>
          {item.name}
        </li>
      ))}
    </ul>
  );
}

Some events arrive in bursts — one input event per keystroke, dozens of resize events while a window is dragged — but you only care about the state at the end of the burst. Running an API search on every keystroke wastes requests and can show results out of order.

Debouncing waits until events stop for a set time, then runs the function once. Ideal for search-as-you-type, resize handlers, autosave and form validation.

The name comes from electronics: a mechanical switch "bounces" and sends several signals for one press, and debouncing collapses them into one. A good mental model is a lift door: every person who steps in resets the close timer, and the door only closes once nobody has entered for a few seconds.

function debounce(func, delay) {
  let timeoutId;

  return function (...args) {
    clearTimeout(timeoutId); // cancel the previously scheduled call
    timeoutId = setTimeout(() => func.apply(this, args), delay); // keep `this` and args
  };
}

function searchQuery(query) {
  console.log("Searching for:", query);
}

const debouncedSearch = debounce(searchQuery, 300);

document.getElementById("search-input").addEventListener("input", (event) => {
  debouncedSearch(event.target.value); // fires once, 300ms after typing stops
});

Throttling runs the function at most once every N ms, no matter how often the event fires. Ideal for scroll position, mousemove, drag and window resize when you need continuous updates but not hundreds per second.

Debounce waits for silence, so during a long scroll it would never run at all. Throttle guarantees a steady rhythm while the burst is still going. A mental model: a shuttle bus that leaves at most once every 200ms. However many passengers turn up, departures are spaced out — and a passenger who arrives just after a bus has left still gets the next one (the trailing call), so the last event isn't dropped.

function throttle(func, interval) {
  let lastCall = 0;
  let timeoutId;
  let lastArgs;
  let lastThis;

  return function (...args) {
    const now = Date.now();
    const remaining = interval - (now - lastCall);
    lastArgs = args;                         // always remember the newest event
    lastThis = this;

    if (remaining <= 0) {
      clearTimeout(timeoutId);
      timeoutId = undefined;
      lastCall = now;
      func.apply(this, args);                // leading call
    } else if (!timeoutId) {
      timeoutId = setTimeout(() => {         // trailing call, so the last event isn't lost
        lastCall = Date.now();
        timeoutId = undefined;
        func.apply(lastThis, lastArgs);
      }, remaining);
    }
  };
}

window.addEventListener("scroll", throttle(() => {
  console.log("scroll position:", window.scrollY);
}, 200));

const log = throttle((label) => console.log("ran with", label), 200);

for (const t of [0, 60, 120, 180, 240, 300]) {
  setTimeout(() => log(`event@${t}`), t);
}
// ran with event@0     (at ~0ms)
// ran with event@180   (at ~200ms)
// ran with event@300   (at ~400ms)

let ticking = false;

window.addEventListener("scroll", () => {
  if (ticking) return;
  ticking = true;
  requestAnimationFrame(() => {
    updateHeader(window.scrollY);
    ticking = false;
  });
}, { passive: true });

Touch and wheel listeners can call preventDefault() to stop scrolling, so the browser normally has to wait for your handler to finish before it scrolls — any slow handler makes scrolling janky.

Why that hurts: modern browsers scroll on a separate compositor thread, so scrolling can stay smooth even while the main thread is busy running JavaScript. But if a touchmove or wheel listener might cancel the scroll, the compositor can't move the page until the main thread has run that listener and reported back. A busy main thread — a long task, a slow handler — then freezes the scroll, even if your handler never cancels anything.

Marking a listener passive: true promises you won't call preventDefault(), so the browser can scroll immediately on the compositor thread.

window.addEventListener(
  "touchmove",
  (e) => {
    updateParallax(window.scrollY);
    // e.preventDefault() here would be ignored (and log a warning)
  },
  { passive: true },
);

carousel.addEventListener(
  "touchmove",
  (e) => {
    if (isHorizontalSwipe(e)) e.preventDefault(); // stop the page scrolling while swiping slides
  },
  { passive: false },
);

button.addEventListener("click", loadEditor, { once: true }); // runs on the first click only

const controller = new AbortController();
window.addEventListener("resize", onResize, { signal: controller.signal });
window.addEventListener("keydown", onKey, { signal: controller.signal });
controller.abort(); // removes both listeners at once

There are three common ways to keep small pieces of data in the browser. Web Storage — localStorage and sessionStorage — is a simple key/value store of strings, scoped to the page's origin (scheme + host + port, so http:// and https:// versions of a site have separate storage). Cookies are older and were designed for the server: the browser attaches them to HTTP requests automatically, which is both their purpose and their cost.

A mental model: localStorage is a drawer in your desk — it stays until someone empties it. sessionStorage is a sticky note on this one tab — reloading keeps it, closing the tab throws it away. A cookie is a badge you show at every door you walk through, whether the door needs it or not.

The Web Storage API is synchronous — every read and write blocks the main thread — so keep it to small values like preferences. For large or structured data, use IndexedDB.

localStorage.setItem("theme", "dark");          // values are always strings
localStorage.getItem("theme");                  // "dark"
localStorage.setItem("user", JSON.stringify({ id: 1 }));
JSON.parse(localStorage.getItem("user"));

// React to changes made in OTHER tabs
addEventListener("storage", (e) => console.log(e.key, e.newValue));

document.cookie = "theme=dark; max-age=31536000; path=/; SameSite=Lax";
document.cookie = "lang=en; path=/";
console.log(document.cookie); // "theme=dark; lang=en"

When several rules target the same element, the browser picks the one with the highest specificity.

Specificity is one step of the cascade, the algorithm that decides which declaration wins when several set the same property on the same element. In order, the cascade looks at: origin and !important, then cascade layers, then specificity, then source order. Specificity is the step interview questions are usually about. It's computed from the selector text alone — never from the HTML, or from how many elements the selector matches.

The best mental model is a version number rather than a decimal number: 1.0.0 beats 0.12.0 because the first column is compared first, and the next column only matters on a tie. There is no carrying between columns, so one ID beats any number of classes. Think of it as a score with columns compared left to right:

<h1 class="title" id="header">Hello</h1>

#header { color: red; }   /* (1, 0, 0) — wins */
.title  { color: blue; }  /* (0, 1, 0) */
h1      { color: green; } /* (0, 0, 1) */

ul li.active a { }        /* (0, 1, 3) */
.nav .item     { }        /* (0, 2, 0) — beats the one above: B column is compared first */

#nav > ul li:hover a::before { }    /* (1, 1, 4) */
input[type="text"]:not(.disabled) { } /* (0, 2, 1) */
:is(#main, .sidebar) p { }          /* (1, 0, 1) */
:where(#main, .sidebar) p { }       /* (0, 0, 1) */

p { color: blue !important; }
#special { color: red; }  /* loses, even though the ID is more specific */

@layer base, components;

@layer components {
  .btn { color: white; }       /* (0, 1, 0) — wins: later layer */
}

@layer base {
  #app .btn { color: black; }  /* (1, 1, 0) — loses despite the ID */
}

#article { color: red; }   /* very specific… */
p { color: black; }        /* …but this targets the <p> directly, so the <p> is black */