The DOM and events

An event travels TWICE: down from window to the target (capturing phase), then back up to window (bubbling phase). Listeners default to bubble-phase; pass { capture: true } to catch the way down. Almost all everyday code uses bubbling (delegation depends on it); capturing is for intercepting events before descendants see them, like global shortcuts or modal traps.

One listener on a parent, using event.target to find which child was actually hit — instead of a listener per child. It is faster to set up, uses constant memory, and automatically covers children added LATER (the killer feature for dynamic lists). The classic demo: one <ul> listener handling delete buttons for rows that don't exist yet. Pair it with closest() to find the relevant ancestor.

stopPropagation halts the event's JOURNEY (no more listeners up or down the tree); preventDefault cancels the browser's DEFAULT ACTION (follow the link, submit the form) while the event keeps traveling. They compose: a validated form calls preventDefault always, stopPropagation only when ancestors must not react. Mixing them up either breaks delegation or lets the page navigate away mid-handler.

target is where the event STARTED (the clicked button); currentTarget is whose listener is RUNNING right now (the <ul> you delegated to). They coincide only without delegation. The standard delegation line reads e.target.closest('li') inside a currentTarget handler — target finds the item, currentTarget anchors the list. Confusing them breaks every delegated handler.

Because listeners attach to elements that exist at bind time — rows added later were never bound. Fixes, best first: delegate from a stable parent (future rows included automatically); re-bind after each render (fragile, leaks duplicates); or bind at creation inside the row factory. If an interview demo "works until I add a row", delegation is the expected diagnosis and the expected fix.

With textContent (or createElement + textContent), never innerHTML with user strings — innerHTML parses markup, so a username containing script markup or an onerror image runs attacker code (XSS). textContent treats everything as inert text. The rule is absolute for beginners: innerHTML only with developer-written, static markup; everything from users goes through textContent.

input fires on EVERY keystroke (live search, validation-as-you-type); change fires on COMMIT (blur for text, selection for dropdowns and checkboxes — the "final answer" event); click is for buttons and toggles. Debounce belongs on input, saves belong on change/submit. Using click on a text field or change for live feedback are the two classic mismatches.

They wait. Handlers and timer callbacks are tasks like any other: while your code runs, clicks queue silently and timers go overdue, then everything fires in order once the stack clears. Users experience this as frozen buttons and late updates during heavy work — the same single-thread story as blocking, wearing an events costume. Keep handlers short or yield.

The listener removes ITSELF after its first run — perfect for one-shot onboarding tips, first-click analytics, and any "do this exactly once" wiring. It also prevents the classic leak of forgotten listeners on temporary UI. For repeated handling with automatic cleanup on teardown, pair a normal listener with AbortController's signal instead.

Pass { signal } at bind time; controller.abort() removes every listener sharing that signal in one call — no function-reference bookkeeping, no missed removals. It is the modern teardown for components: one controller per mount, abort on unmount. Bonus: the same signal can cancel the component's fetches, unifying DOM and network cleanup.