Why does a Promise callback run before setTimeout?

Promise callbacks are microtasks, and `setTimeout` callbacks are macrotasks. After each task finishes, the event loop drains the entire microtask queue before running the next macrotask or rendering. So a resolved promise's `.then` always executes before a `setTimeout(fn, 0)`, even when both are scheduled at the same moment.

Why is `this` undefined in my callback?

Because `this` depends on how a function is called, not where it is defined. Passing a method as a callback detaches it from its object, so the implicit binding is lost. Fix it by using an arrow function, which captures `this` lexically, or by binding the method explicitly with `Function.prototype.bind`.

Is JavaScript single-threaded or multi-threaded?

JavaScript executes your code on a single main thread using an event loop, so only one piece of code runs at a time. Concurrency comes from offloading work to the host environment, such as timers, network requests, and Web Workers. Workers run on separate threads but communicate through messages, not shared call stacks.

Should I use ES modules or CommonJS?

Prefer ES modules for new code. They are the language standard, use static `import`/`export` that enables tree shaking and smaller bundles, support top-level `await`, and run natively in browsers and modern Node.js. CommonJS with `require` is still common in older Node projects, but ESM is the forward-looking default.

Understanding JavaScript Closures

This is a practical, up-to-date guide to Understanding JavaScript Closures — what it is, why it matters in 2026, and how to apply it in real projects. It is written for developers and founders who want clear answers and proven best practices, not filler.

Whether you're just starting out or leveling up, treat this as a working reference you can return to. Every section is built to be skimmed, applied, and shared.

How Does the JavaScript Event Loop Work?

JavaScript runs on a single thread with a call stack, a task (macrotask) queue, and a microtask queue. The engine takes one task, runs it to completion, then empties the entire microtask queue before doing anything else. Only after microtasks drain does the browser get a chance to render and pick the next task.

The ordering matters in practice:

Synchronous code on the call stack runs first.
Promise reactions and queueMicrotask callbacks run next, fully draining.
Timers, I/O, and events run as later macrotasks.

This is why a Promise.resolve().then(...) always fires before a setTimeout(..., 0). Long synchronous work blocks the loop entirely, freezing input and rendering, which is the root cause of jank.

What Is a JavaScript Closure?

A closure is created every time a function is defined: the function keeps a live reference to the variables in the scope where it was declared, not where it is called. Because the inner function holds that reference, those variables survive after the outer function has returned. This is the mechanism behind data privacy, function factories, and stable callbacks.

A practical example is a counter:

function makeCounter() {
  let count = 0;
  return () => ++count;
}
const next = makeCounter();
next(); // 1
next(); // 2

The returned arrow function closes over count. Each makeCounter() call produces an independent count, so two counters never interfere. Closures are not copies of values; they share the actual binding, which is why loop variables declared with var historically caused surprises that let fixes.

How Do ES Modules Differ From CommonJS?

ES modules (ESM) are the standardized module system defined by ECMAScript and supported natively in browsers and Node.js. CommonJS (CJS) is Node's original system built on require and module.exports. The differences are not just syntax; they affect loading and tooling.

ESM uses static import/export, enabling tree shaking and dead-code elimination.
CJS uses dynamic require, resolved synchronously at runtime.
ESM bindings are live read-only views; CJS exports are copied values.
ESM is asynchronous and supports top-level await; CJS is synchronous.

New projects should default to ESM for better static analysis and smaller bundles. Use dynamic import() to load code on demand, which also returns a promise and integrates cleanly with async/await.

What Causes Memory Leaks in JavaScript?

JavaScript is garbage collected, but objects are only freed when nothing references them. Leaks happen when references outlive their usefulness, so the collector cannot reclaim memory. Over time this grows the heap and degrades performance, especially in long-lived single-page apps.

Common culprits:

Timers and intervals that are never cleared.
Event listeners left attached to removed elements.
Detached DOM nodes still referenced by JavaScript variables.
Caches, maps, and arrays that grow without bound.
Closures that unintentionally retain large objects.

Use the DevTools Memory panel and heap snapshots to find retained objects, and prefer WeakMap/WeakSet for associations that should not prevent collection. Always pair addEventListener and setInterval with their cleanup.

How Do You Optimize JavaScript Performance?

The biggest wins come from doing less on the main thread, not from clever micro-optimizations. Profile first with the browser Performance panel or Lighthouse, find the long tasks, then attack them. Optimize for the metric users feel: Interaction to Next Paint should stay under 200 ms.

High-impact techniques:

Break long tasks into chunks and yield with scheduler.yield() or setTimeout.
Move CPU-heavy work to a Web Worker so the UI thread stays free.
Debounce or throttle high-frequency events like scroll, resize, and input.
Defer non-critical scripts and code-split large bundles.
Batch DOM reads and writes to avoid layout thrashing.

Measure again after each change; assumptions about hotspots are often wrong.

When Should You Use Promises vs Callbacks?

Callbacks are still appropriate for simple, synchronous-style APIs and for event handlers that fire many times. For one-shot asynchronous results, promises and async/await are almost always the better choice: they flatten nesting, propagate errors predictably, and compose with combinators.

Promises shine when coordinating multiple operations:

Promise.all waits for everything and rejects fast on the first failure.
Promise.allSettled waits for all results regardless of failures.
Promise.race resolves with the first settled promise.
Promise.any resolves with the first success, ignoring rejections.

The classic "callback hell" of deeply nested handlers disappears once you return promises and chain or await them. Mixing both styles in one flow, however, is a frequent source of swallowed errors.