JS Fundamentals at Depth

1The frame — lexical vs runtime

Most JS “gotchas” come from confusing two questions the language answers at different times: [MDN]

Then two more that are really build/architecture concerns: the module system (ESM vs CJS, §6) and event delegation (§7). Keep the frame in hand and each section is a corollary.

2Scope, hoisting & the TDZ — var / let / const

The Temporal Dead Zone is the window from the start of a block until the let/const declaration line: the binding exists (it's hoisted) but touching it throws. It exists to catch use-before-declare bugs that var silently swallowed. [MDN] And const freezes the binding, not the value: const a = []; a.push(1) is fine; a = [] throws.

3Closures — a function + the scope it remembers

A closure is a function bundled with the lexical environment it was declared in — it keeps access to those outer variables even after the outer function has returned. It's the mechanism behind data privacy, function factories, and React's useState. [MDN]

function counter() {
  let n = 0;                 // private — only the returned fns can see it
  return { inc: () => ++n, get: () => n };
}
const c = counter(); c.inc(); c.inc(); c.get();  // → 2

The interview classic — predict the logs:

for (var i = 0; i < 3; i++) setTimeout(() => console.log(i));   // 3 3 3
for (let i = 0; i < 3; i++) setTimeout(() => console.log(i));   // 0 1 2

With var there's one i shared by all three closures; by the time the timers fire (next macrotask, Lesson 11), the loop has finished and i is 3. With let, each iteration gets a fresh block-scoped binding, so each closure captures its own i. Same lexical rule, different bindings.

4this — decided by the call site

The most-asked and most-missed. this is not about where a function is written — it's about how it's called. Four rules, highest precedence first: [MDN]

Arrow functions break the rule — on purpose. An arrow has no this of its own; it uses the this of the enclosing lexical scope (back to the frame). That's why arrows are perfect for callbacks inside a method. The classic bug and its fixes:

const obj = { name: 'A', hi() { return this.name; } };
const f = obj.hi;  f();        // ✗ undefined — bare call, lost `this`
setTimeout(obj.hi, 0);          // ✗ same problem — passed as a plain fn
setTimeout(() => obj.hi(), 0);    // ✓ arrow keeps the obj.hi() call form
setTimeout(obj.hi.bind(obj), 0); // ✓ bind pins `this` = obj

5Prototypes — objects linked to objects

JS inheritance is prototypal, not classical. Every object has a hidden link ([[Prototype]]) to another object; reading a property walks up that chain until it's found or the chain hits null. [MDN]

arr.map(...)        // arr → Array.prototype (map lives here) → Object.prototype → null

class is syntactic sugar over this. A class's methods live once on the prototype (shared by all instances), not copied per object — which is why they're memory-efficient. extends just links one prototype to another; instanceof checks whether a prototype appears in the chain. Knowing it's prototypes underneath explains why you can monkey-patch Array.prototype and why method lookup is a chain walk.

6Modules — ESM vs CJS (and why tree-shaking needs ESM)

Two module systems, and the difference is static vs dynamic — which is exactly why one tree-shakes and the other can't (Lesson 05). [Node]

Why the last row: because ESM import/export are static, a bundler can tell at build time exactly which exports are used without running the code, and drop the rest. CJS's require is a dynamic call that can be conditional or computed (require(someVar)), so the bundler can't safely prove an export is unused. Static structure is the prerequisite for tree-shaking (Lesson 05's sideEffects:false lives here too).

7Event delegation — one listener, many children

Events bubble: a click on a child fires on the child, then its parent, up the ancestors (Lesson 11 — events are macrotasks). Delegation exploits that: attach one listener on a common ancestor and read event.target (often via .closest()) to find which child was hit. [MDN]

list.addEventListener('click', (e) => {
  const item = e.target.closest('li');
  if (item) select(item.dataset.id);     // one handler for all current AND future <li>
});

Why a Lead reaches for it: one listener instead of N (less memory and setup — ties to Lessons 07/08), and it automatically covers dynamically added/removed children — perfect for a virtualized hotel list or an infinite-scroll feed where rows come and go. Caveats: only works for events that bubble (most do; focus/blur don't — use focusin), and you must filter target so unrelated clicks are ignored.

Capturing vs bubbling — the round trip that makes delegation work

“Bubbling” is half of a three-phase round trip every event makes through the DOM: [MDN]

1. Capture — travels down from the root: window → document → … → target's parent.
2. Target — reaches the element you actually hit.
3. Bubble — travels back up: target → … → document → window.

addEventListener defaults to the bubble phase — which is exactly why delegation works (the child's click bubbles up to your parent listener). Opt into capture with a flag; capture listeners fire first (top-down), so they're for intercepting an event before the target sees it:

parent.addEventListener('click', fn);                // bubble (default)
parent.addEventListener('click', fn, { capture: true }); // capture — fires before target
// order: capturing (outer→inner) → target → bubbling (inner→outer)

8The Lead framing

9Check yourself — scenario quiz

Pick an answer; instant feedback. Push-back style, like the round.