Complete JavaScript Tutorial

JavaScript is the only language most developers cannot avoid, which means it is also the language most people learn by accretion — a framework here, a Stack Overflow answer there — without ever assembling the underlying model. That works for a long time and then produces a specific kind of confusion: code that behaves differently than it reads.

Four mechanisms account for nearly all of it. The event loop decides when your code runs. Closures decide what it can see. The this binding rules decide what it is operating on. Prototypes decide where properties come from. Learn those four and the language stops surprising you — including the parts frameworks are built on.

The event loop, and why setTimeout(fn, 0) is not immediate

JavaScript runs on one thread with a queue. Synchronous code runs to completion. Then every queued microtask runs — promise callbacks, queueMicrotask — including microtasks queued during that drain. Only then does one macrotask run: a timer callback, an I/O event, a DOM event.

That ordering explains a whole family of behaviours: why setTimeout(fn, 0) runs after every pending promise, why a long synchronous loop freezes the UI completely, and why await inside a loop serialises requests that you probably meant to run concurrently.

console.log('a');
setTimeout(() => console.log('b'), 0);          // macrotask
Promise.resolve().then(() => console.log('c')); // microtask
console.log('d');
// a, d, c, b

// Serial: each await waits for the previous request
for (const id of ids) results.push(await fetchOne(id));

// Concurrent: start them all, then wait
const results = await Promise.all(ids.map(fetchOne));

// Concurrent but tolerant of individual failures
const settled = await Promise.allSettled(ids.map(fetchOne));
const ok = settled.filter(r => r.status === 'fulfilled').map(r => r.value);

Equality, coercion, and the two comparisons worth using

== applies a coercion algorithm that produces results nobody memorises reliably. === compares type and value with no coercion. Use === everywhere, with one idiomatic exception: x == null is a concise check for both null and undefined.

The distinction between those two is worth being precise about, because modern syntax depends on it. undefined means never assigned; null means deliberately empty. ?? falls back only for those two, while || falls back for every falsy value — which is why count || 10 turns a legitimate zero into ten and count ?? 10 does not.

Closures are the language's most-used feature

A closure is a function that retains access to the variables of the scope it was created in — the variables themselves, not copies of their values. That distinction is the entire explanation for the classic loop puzzle, and for why let fixes it: var creates one function-scoped binding shared by every callback, while let creates a fresh binding per iteration.

Closures are also the mechanism behind most patterns you already use: module privacy, memoisation, debounce and throttle, React hooks holding state between renders, and every callback that remembers something from where it was defined.

// Debounce: the timer id lives in the closure, private to each instance
function debounce(fn, ms) {
  let timer;
  return (...args) => {
    clearTimeout(timer);
    timer = setTimeout(() => fn(...args), ms);
  };
}

// Throttle: allow at most one call per interval
function throttle(fn, ms) {
  let last = 0;
  return (...args) => {
    const now = Date.now();
    if (now - last >= ms) { last = now; fn(...args); }
  };
}

// Debounce a search box (wait for quiet); throttle a scroll handler
// (steady rate). Using the wrong one is a common performance bug.

Modules, bundling and what actually ships

ES modules are static: imports are resolved before execution, which is what makes tree shaking possible — a bundler can prove a named export is unused and drop it. CommonJS require is a synchronous function call resolved at runtime, so it cannot be analysed the same way. That single difference explains most bundler behaviour and most of the interop friction between the two.

It also has a practical consequence worth carrying into code review: a default export of a large object, or a barrel file re-exporting an entire library, defeats tree shaking and can put hundreds of kilobytes into a bundle for one function. Named imports from the specific module are not a style preference — they are what lets the bundler remove what you do not use.