JavaScript Interview Questions

TL;DR

"Hoisting" is informal shorthand for how JavaScript creates and initializes bindings while it instantiates a scope, before evaluating that scope's statements. The engine does not move source text.

• Variable declarations (var): The binding is created and initialized to undefined before statements run. Its assignment still happens at the declaration's source location.
• Variable declarations (let and const): The binding is created but remains uninitialized in the temporal dead zone (TDZ) until evaluation reaches the declaration. Accessing it earlier throws ReferenceError.
• Function expressions (var): The var binding initially contains undefined; the function is created only when the expression is evaluated.
• Function declarations (function): The binding is initialized with the function during scope setup, so it can be called before its declaration appears in source order.
• Class declarations (class): The binding exists during scope setup but remains in the TDZ until the class declaration is evaluated.
• Import declarations (import): Imported bindings are linked before module evaluation. Dependencies normally evaluate before the importing module's body, although cycles can expose an uninitialized binding.

The following behavior summarizes the result of accessing the variables before they are declared.

Declaration setup and execution

“Hoisting” describes the observable result of declaration instantiation before statements execute; the source text is not rearranged.

This model explains why different declarations are all commonly called “hoisted” even though early access produces different results.

Hoisting

Hoisting is a term used to explain the behavior of declarations in JavaScript code.

Before evaluating statements in a scope, JavaScript instantiates its declarations and creates their bindings. A var binding is initialized to undefined at that point; an initializer or later assignment still runs at its original source location. No declaration is physically moved.

Let's explain with a few code samples. Note that the code for these examples should be executed within a module scope instead of being entered line by line into a REPL like the browser console.

Hoisting of variables declared using var

Hoisting is visible here: even though foo is declared and initialized after the first console.log(), the first console.log() prints undefined.

console.log(foo); // undefined
var foo = 1;
console.log(foo); // 1

You can visualize the code as:

var foo;
console.log(foo); // undefined
foo = 1;
console.log(foo); // 1

Hoisting of variables declared using let, const, and class

Bindings declared via let, const, and class are also created during scope instantiation. Unlike var and function declarations, they remain uninitialized, and accessing them before evaluation reaches the declaration throws ReferenceError. This interval is the temporal dead zone.

y; // ReferenceError: Cannot access 'y' before initialization
let y = 'local';

z; // ReferenceError: Cannot access 'z' before initialization
const z = 'local';

Foo; // ReferenceError: Cannot access 'Foo' before initialization

class Foo {
  constructor() {}
}

Hoisting of function expressions

A function expression is a function assigned to a variable binding. When the binding uses var, scope setup initializes it to undefined; the function object is not created until evaluation reaches the expression.

console.log(bar); // undefined
bar(); // TypeError: bar is not a function

var bar = function () {
  console.log('BARRRR');
};

Arrow functions are function expressions too, so the same rule applies — only the binding is hoisted, and its TDZ behavior follows the declaration keyword (var initializes to undefined, let and const remain in the TDZ until their declaration runs).

console.log(baz); // undefined
var baz = () => 'arrow';
console.log(baz()); // 'arrow'

Hoisting of function declarations

Function declarations use the function keyword. Unlike function expressions, their bindings are initialized with the function during scope setup, so they can be called before their declarations appear in source order.

console.log(foo); // [Function: foo]
foo(); // 'FOOOOO'

function foo() {
  console.log('FOOOOO');
}

The same applies to generator functions (function*), async functions (async function), and async generator functions (async function*).

Hoisting of import statements

Import declarations are hoisted. The identifiers the imports introduce are available in the entire module scope, and their side effects are produced before the rest of the module's code runs.

foo.doSomething(); // Works normally.

import foo from './modules/foo';

Under the hood

In reality, JavaScript creates all variables in the current scope before it even tries to execute the code. Variables created using the var keyword will have the value of undefined, whereas variables created using the let and const keywords will be marked as <value unavailable>. Thus, accessing them will cause a ReferenceError, preventing you from accessing them before initialization.

In the ECMAScript specification, let and const declarations are explained as below:

The variables are created when their containing Environment Record is instantiated but may not be accessed in any way until the variable's LexicalBinding is evaluated.

However, this statement is a little different for the var keyword:

Var variables are created when their containing Environment Record is instantiated and are initialized to undefined when created.

MDN groups hoisting into four observable behaviors, which map to the declaration kinds covered above:

1. Value hoisting — the value is usable before the declaration. Applies to function declarations.
2. Declaration hoisting — the binding is usable before the declaration but reads undefined. Applies to var.
3. Scope tainting — the binding exists from the top of the scope but any access throws (the TDZ). Applies to let, const, and class.
4. Side effects — the declaration's side effects run before the rest of the module evaluates. Applies to import.

Modern practices

In practice, modern codebases avoid using var and use let and const exclusively. It is recommended to declare and initialize your variables and import statements at the top of the containing scope/module to eliminate the mental overhead of tracking when a variable can be used.

ESLint is a static code analyzer that can find violations of such cases with the following rules:

• no-use-before-define: Warns when an identifier is referenced before its declaration appears in source.
• no-undef: Warns when an identifier is referenced without being declared anywhere in scope.

Additional examples

The examples below cover hoisting behaviors that are less obvious from the summary table and that commonly cause confusion.

Function declaration compared with function expression

console.log(declared());
console.log(expressed());

function declared() {
  return 'function declaration';
}

var expressed = function () {
  return 'function expression';
};

• declared() returns 'function declaration'. The declared binding is initialized with the function before statement evaluation begins.
• expressed() throws TypeError: expressed is not a function. Scope setup initializes the var expressed binding to undefined, but the assignment of the function expression happens at its source location. Calling undefined() produces the TypeError.

var in a for loop with setTimeout

for (var i = 0; i < 3; i++) {
  setTimeout(() => console.log(i), 0);
}
// Output: 3, 3, 3

var i is function-scoped rather than block-scoped, so all three callbacks close over the same binding. The loop increments i to 3 before any setTimeout callback runs, because macrotasks run after the current synchronous code completes. Each callback then reads the current value of the shared i, which is 3.

Two fixes:

• Replace var with let. let is block-scoped, so each iteration creates a fresh binding that the callback closes over.
• Wrap the body in an IIFE that captures the current value as a parameter: (i => setTimeout(() => console.log(i), 0))(i). This was the pre-ES6 workaround.

var escapes block scope

if (true) {
  var a = 1;
  let b = 2;
}
console.log(a); // 1
console.log(b); // ReferenceError: b is not defined

var is scoped to the nearest function or script, not to the enclosing block. Its binding therefore belongs to the containing function or script scope, which is why a is still visible after the if. let and const are block-scoped, so b only exists inside the block.

Redeclaration

var x = 1;
var x = 2; // OK — x is now 2

let y = 1;
let y = 2; // SyntaxError: Identifier 'y' has already been declared

var allows the same name to be redeclared in the same scope; the second declaration is a no-op and only the assignment runs. let, const, and class throw SyntaxError if the same name is declared twice in the same scope. Like hoisting, this is resolved statically before execution — duplicate lexical declarations are an early error detected during parsing, so no code runs at all.

Class declarations

console.log(typeof Foo);

class Foo {}

This throws ReferenceError: Cannot access 'Foo' before initialization.

The Foo binding is created when the enclosing block is instantiated, but it remains in the Temporal Dead Zone until the class declaration is evaluated. Any access before that point throws, including typeof.

This behavior can be confused with "classes are not hoisted". The two statements are observably different:

• If Foo were not hoisted, typeof Foo would return 'undefined' (the behavior for truly undeclared identifiers).
• Because Foo is hoisted but uninitialized, typeof Foo throws.

The distinction also matters for extends clauses, which are evaluated at class declaration time. class A extends B {} throws if B is hoisted but still in the TDZ at that point.

typeof and the Temporal Dead Zone

console.log(typeof undeclaredVariable); // 'undefined'
console.log(typeof someLet); // ReferenceError
let someLet = 1;

typeof does not throw when applied to an identifier that has no declaration anywhere in scope — it returns the string 'undefined'. However, typeof does throw when applied to an identifier that is declared but still in the Temporal Dead Zone. The binding exists, and reading it (which typeof must do) triggers the TDZ error.

This distinguishes "undeclared" (no binding in any enclosing scope) from "declared but uninitialized" (binding exists, initialization has not yet occurred).

Shared names across var and function declarations

function outer() {
  console.log(inner);
  inner();

  function inner() {
    console.log('inner called');
  }

  var inner = 'overwritten';
}

outer();
// Output:
// [Function: inner]
// inner called

Two behaviors combine here:

1. Scope instantiation processes both var inner and the function inner declaration before outer's statements run.
2. When a var declaration and a function declaration share a name in the same scope, the function declaration takes precedence during initialization. inner is initialized with the function object rather than undefined.

The var inner = 'overwritten' assignment takes effect only after the two console.log calls, so those calls observe the function. A console.log(inner) after the assignment would print 'overwritten'.

A let or const declaration in the same scope as a var of the same name produces a SyntaxError at parse time, before any code runs.

Common misconceptions

The following statements appear frequently in explanations of hoisting, including in material generated by large language models, but are incorrect or imprecise:

1. Classes are not hoisted. Class bindings are created during scope instantiation but remain in the Temporal Dead Zone until the declaration is evaluated. That is observably different from having no binding — most notably, typeof throws on a class in the TDZ but returns 'undefined' for a truly undeclared identifier.
2. var is hoisted; let and const are not. All three bindings are created before statement evaluation. They differ in initialization: var is initialized to undefined immediately, while let and const remain uninitialized in the TDZ until their declarations are evaluated.
3. typeof never throws on undeclared variables. typeof is safe for identifiers that have no declaration anywhere in scope, but it throws in the TDZ. The typeof x === 'undefined' guard is only safe if x is not declared anywhere in the enclosing scope.
4. Function declarations are hoisted; function expressions are not. A declaration's binding is initialized with its function during scope setup. An expression creates its function only when that expression is evaluated: a var binding contains undefined before then, while a let or const binding remains in the TDZ.

Further reading

• Hoisting | MDN
• ECMA-262 §14.2.6 Block Runtime Semantics: Evaluation
• Temporal Dead Zone | MDN
• What is Hoisting in JavaScript?

Exercises

TL;DR

In JavaScript, let, var, and const are all keywords used to declare variables, but they differ significantly in terms of scope, initialization rules, whether they can be redeclared or reassigned, and the behavior when they are accessed before declaration:

Scope and initialization at a glance

The important difference is not whether a declaration is “moved”, but when its binding is created, initialized, and allowed to change.

const prevents rebinding; it does not make an object value immutable.

Differences in behavior

Let's look at the difference in behavior between var, let, and const.

Scope

Variables declared using the var keyword are scoped to the function in which they are created, or if created outside of any function, to the global object. let and const are block scoped, meaning they are only accessible within the nearest set of curly braces (function, if-else block, or for-loop).

function foo() {
  // All variables are accessible within functions.
  var bar = 1;
  let baz = 2;
  const qux = 3;

  console.log(bar); // 1
  console.log(baz); // 2
  console.log(qux); // 3
}

foo(); // Prints each variable successfully
console.log(bar); // ReferenceError: bar is not defined
console.log(baz); // ReferenceError: baz is not defined
console.log(qux); // ReferenceError: qux is not defined

In the following example, bar is accessible outside of the if block but baz and qux are not.

if (true) {
  var bar = 1;
  let baz = 2;
  const qux = 3;
}

// var variables are accessible anywhere in the function scope.
console.log(bar); // 1
// let and const variables are not accessible outside of the block they were defined in.
console.log(baz); // ReferenceError: baz is not defined
console.log(qux); // ReferenceError: qux is not defined

Initialization

var and let variables can be initialized without a value but const declarations must be initialized.

var foo; // Ok
let bar; // Ok
const baz; // SyntaxError: Missing initializer in const declaration

Redeclaration

Redeclaring a variable with var will not throw an error, but let and const will.

var foo = 1;
var foo = 2; // Ok
console.log(foo); // Should print 2, but SyntaxError from baz prevents the code executing.

let baz = 3;
let baz = 4; // Uncaught SyntaxError: Identifier 'baz' has already been declared

Reassignment

var and let allow reassigning the variable's value while const does not.

var foo = 1;
foo = 2; // This is fine.

let bar = 3;
bar = 4; // This is fine.

const baz = 5;
baz = 6; // Uncaught TypeError: Assignment to constant variable.

Accessing before declaration

var ,let and const declared variables are all hoisted. var declared variables are auto-initialized with an undefined value. However, let and const variables are not initialized and accessing them before the declaration will result in a ReferenceError exception because they are in a "temporal dead zone" from the start of the block until the declaration is processed.

console.log(foo); // undefined
var foo = 'foo';

console.log(baz); // ReferenceError: Cannot access 'baz' before initialization
let baz = 'baz';

console.log(bar); // ReferenceError: Cannot access 'bar' before initialization
const bar = 'bar';

Notes

• In modern JavaScript, it's generally recommended to use const by default for variables that don't need to be reassigned. This promotes immutability and prevents accidental changes.
• Use let when you need to reassign a variable within its scope.
• Avoid using var due to its potential for scoping issues and hoisting behavior.
• If you need to target older browsers, write your code using let/const, and use a transpiler like Babel to compile your code to older syntax.

Further reading

• The Difference of "var" vs "let" vs "const" in JavaScript

Exercises

TL;DR

== is the abstract equality operator while === is the strict equality operator. == performs type coercion before comparing, following the Abstract Equality Comparison algorithm defined in the ECMAScript specification. === does not perform coercion and returns false whenever the operand types differ. === is generally preferred in application code because it eliminates a class of bugs caused by unexpected coercion. The most common exception is x == null, which checks for both null and undefined in a single comparison.

Don't confuse = with == and ===. = is the assignment operator — it sets a variable's value (x = 5) and does not compare anything.

The Abstract Equality Comparison algorithm

The behavior of == is defined by the IsLooselyEqual algorithm in ECMA-262 §7.2.15. Given operands x and y, the algorithm proceeds as follows:

1. If Type(x) is the same as Type(y), return the result of x === y (strict equality, without coercion).
2. If x is null and y is undefined, return true.
3. If x is undefined and y is null, return true.
4. If Type(x) is Number and Type(y) is String, return x == ToNumber(y).
5. If Type(x) is String and Type(y) is Number, return ToNumber(x) == y.
6. If Type(x) is BigInt and Type(y) is String, convert y with StringToBigInt. Return false if the conversion is undefined; otherwise compare the resulting BigInts.
7. If Type(x) is String and Type(y) is BigInt, swap operands and apply step 6.
8. If Type(x) is Boolean, return ToNumber(x) == y.
9. If Type(y) is Boolean, return x == ToNumber(y).
10. If Type(x) is String, Number, BigInt, or Symbol, and Type(y) is Object, return x == ToPrimitive(y).
11. If Type(x) is Object and Type(y) is String, Number, BigInt, or Symbol, return ToPrimitive(x) == y.
12. If one operand is a BigInt and the other is a Number, return true if the mathematical values are equal; otherwise false.
13. Return false.

Four properties of the algorithm that are not apparent from a truth table alone:

• Boolean operands are always converted to Number first (via step 8 or 9). This is why true == '1' is true: true becomes 1, then step 5 converts '1' to 1, producing 1 == 1.
• Object operands are reduced to primitives via ToPrimitive (steps 10 and 11), which invokes Symbol.toPrimitive, then valueOf, then toString. For example, [1] == 1 is true because [1].toString() is '1', which then coerces to 1.
• null and undefined are only loose-equal to each other and to themselves (steps 2 and 3). They are not coerced to 0 or false elsewhere in the algorithm, which is why a == null is a valid idiom for testing "null or undefined".
• NaN is not equal to any value, including itself, under any equality operator. Use Number.isNaN(x) or Object.is(x, NaN) to test for it.

The coercion helpers used by ==

== dispatches to three type-conversion routines defined in ECMA-262 §7.1:

• ToPrimitive(input, hint) — returns the input unchanged if it is already a primitive. Otherwise invokes input[Symbol.toPrimitive](hint), then falls back to valueOf() and toString(). If none returns a primitive, a TypeError is thrown.
• ToNumber(argument) — undefined becomes NaN; null becomes +0; true and false become 1 and +0; strings are parsed with whitespace trimming, with the empty string becoming 0; Symbols and BigInts throw TypeError; objects are first reduced via ToPrimitive(argument, "number") and the result is recursed on.
• ToString(argument) — undefined becomes "undefined"; null becomes "null"; Booleans become "true" and "false"; Numbers use Number::toString; Symbols throw TypeError; objects are first reduced via ToPrimitive(argument, "string").

Examples

The examples below apply the algorithm above to values that commonly produce unexpected results.

Array compared with boolean

console.log([] == false); // true
console.log([0] == false); // true
console.log([1] == true); // true
console.log([1, 2] == '1,2'); // true

Walking through [] == false:

1. Step 9: false is coerced to 0, producing [] == 0.
2. Step 11: the array is coerced via ToPrimitive. Array.prototype.toString joins elements with commas, so [].toString() is '', producing '' == 0.
3. Step 5: '' == 0 coerces the string to 0, producing 0 == 0.
4. Step 1: same types, strict equality returns true.

The same process explains the remaining cases.

[] == ![]

console.log([] == ![]); // true

Evaluation order:

1. ![] is evaluated first. Applying ToBoolean to any object yields true, so ![] is false.
2. The expression is now [] == false, which evaluates to true via the steps shown above.

Object compared with boolean

console.log({} == false); // false

Walking through:

1. Step 9: false becomes 0, producing {} == 0.
2. Step 11: the plain object is coerced via ToPrimitive. Object.prototype.toString returns '[object Object]'.
3. Step 5: '[object Object]' == 0 calls ToNumber('[object Object]'), which produces NaN.
4. Step 1 with NaN == 0: strict equality returns false.

This differs from [] == false because the two objects have different toString results. This case is a frequent source of incorrect output in AI-generated explanations that treat all objects as equivalent to [] for coercion purposes.

null and undefined

console.log(null == undefined); // true
console.log(null == 0); // false
console.log(null == false); // false
console.log(null >= 0); // true

• null == undefined is true by the special case in step 2.
• null == 0 is false because no step in == converts null to 0.
• null == false is false for the same reason — false becomes 0, but null is not coerced, and step 13 returns false.
• null >= 0 is true because relational operators do not use the Abstract Equality algorithm. They apply ToNumber directly, converting null to 0, producing 0 >= 0.

A consequence: the three expressions null >= 0, null <= 0, and null != 0 are all true simultaneously.

Same-type string comparison does not coerce

console.log(0 == ''); // true
console.log(0 == '0'); // true
console.log('' == '0'); // false

0 == '' and 0 == '0' both convert the string to a number (step 5). '' == '0' is a comparison between two strings; step 1 defers to strict equality, which compares the string contents directly. The strings '' and '0' are not equal.

A consequence: == is not transitive. a == b and a == c together do not imply b == c.

Symbol equality

const s = Symbol('x');
console.log(s == s); // true
console.log(s == 'x'); // false
console.log(s === s); // true

Two Symbols are loosely equal only if they are the same value (step 1). A Symbol compared with a string falls through the algorithm to step 13 and returns false without attempting any coercion that would throw.

Common misconceptions

The following statements appear frequently in documentation, teaching material, and responses generated by large language models, but are incorrect:

1. {} == false is true: It is false. {} coerces to '[object Object]', which coerces to NaN, which is not equal to 0.
2. [] == ![] is false: It is true. ![] is false, and [] == false follows the coercion steps to true.
3. null == false is true because null is falsy: It is false. The == algorithm has no step that coerces null to a boolean or number; ToBoolean is a separate operation used by conditional expressions, not by ==.
4. == is transitive: It is not. 0 == '' and 0 == '0' are both true, but '' == '0' is false.
5. NaN == NaN is true: NaN is not equal to any value under ==, ===, or a relational comparison. Use Number.isNaN(x) or Object.is(x, NaN).

Object.is()

Object.is(x, y) returns the same result as === with two exceptions:

• Object.is(NaN, NaN) is true, whereas NaN === NaN is false.
• Object.is(+0, -0) is false, whereas +0 === -0 is true.

In other words, Object.is() matches === for every value except signed zeros and NaN. Use it when those two cases need to be distinguished from the behavior of ===.

Conclusion

• Using === (strict equality) is generally recommended to avoid the pitfalls of type coercion, which can lead to unexpected behavior and bugs in your code. It makes the intent of your comparisons clearer and ensures that you are comparing both the value and the type.
• Use x == null when a single check for null or undefined is required. ESLint's eqeqeq rule allows this pattern via the { "null": "ignore" } option.
• Use Object.is when NaN equality or distinguishing +0 from -0 is required.
• When questioned about an unexpected == result, work through the algorithm steps rather than relying on memorized truth tables. The algorithm is short and fully specifies the behavior.

Further reading

• ECMA-262 §7.2.15 IsLooselyEqual
• ECMA-262 §7.1 Type conversion
• Equality (==) | MDN
• Strict equality (===) | MDN
• Object.is() | MDN
• ESLint eqeqeq rule

Exercises

console.log(0 == false, 0 === false, null == undefined, null === undefined);

TL;DR

The event loop is the host runtime's scheduling mechanism for coordinating JavaScript jobs, asynchronous operations, and—in browsers—rendering. A simplified browser turn works like this:

1. The host runs one task, such as initial script evaluation, a timer callback, or an input-event callback. Function calls made by that task use the JavaScript agent's call stack.
2. Timers, networking, and other host APIs continue outside the currently executing JavaScript stack. When work becomes ready, the host queues a task or settles a promise, which queues its reactions as microtasks.
3. After the current task finishes and its stack is empty, the runtime performs a microtask checkpoint. It drains promise reactions, queueMicrotask() callbacks, and other microtasks, including microtasks added while the checkpoint is running.
4. The browser may update rendering, then the host selects one eligible task and runs it. After that task, it performs another microtask checkpoint; it does not drain every task queue in one pass.
5. These turns continue for the lifetime of the event loop. An unbounded microtask chain can delay later tasks and rendering.

One browser event-loop turn

The event loop repeatedly runs one task, empties the resulting microtasks, and then gives the browser an opportunity to render before choosing another task.

Timers and I/O do not interrupt the active stack; their completion makes later tasks or promise reactions eligible to run.

Event loop in JavaScript

The event loop lets a JavaScript agent coordinate asynchronous operations without blocking its currently executing stack. Each agent runs one JavaScript job at a time; workers use separate agents and event loops.

Parts of the event loop

To understand it better, we need to understand all the parts of the system. These components are part of the event loop:

Call stack

The call stack keeps track of the functions being executed in a program. When a function is called, it is added to the top of the call stack. When the function completes, it is removed from the call stack. This allows the program to keep track of where it is in the execution of a function and return to the correct location when the function completes. As the name suggests, it is a stack data structure which follows last-in-first-out.

Web APIs/Node.js APIs

Hosts such as browsers and Node.js manage timers, networking, and file I/O outside the currently executing JavaScript stack. The implementation varies: an operation may use operating-system facilities, an evented subsystem, or a worker pool rather than one new thread per operation. When work becomes ready, the host schedules the relevant task or microtask.

Task queue / Macrotask queue / Callback queue

Task queues hold tasks that are ready to run. Browsers may maintain multiple task queues and choose among eligible queues according to the HTML event loop rules; "macrotask queue" is convenient informal terminology, not the specification's single queue.

Microtasks queue

The microtask queue holds promise reactions, queueMicrotask() callbacks, and other microtasks. At a microtask checkpoint, it drains until empty, including newly added microtasks; an unbounded stream can starve later tasks.

Event loop order

1. The host selects and runs one task. Synchronous function calls made by that task are pushed onto and popped from the call stack.
2. Host facilities handle timers, networking, and I/O outside the active JavaScript stack. When their results become ready, they arrange for tasks or promise reactions to be queued.
3. When the task finishes, the runtime performs a microtask checkpoint and drains the microtask queue, including microtasks queued by other microtasks.
4. In a browser, the host may then update rendering. It selects another eligible task according to host-defined scheduling rules and repeats the cycle.

This model is deliberately simplified: browsers can have multiple task queues, and Node.js divides work into event-loop phases. The key ordering rule is that each completed task is followed by a microtask checkpoint before another task runs.

Example

The example below mixes synchronous logs with two timer callbacks and two promise callbacks. The first timer's callback enqueues a microtask, and the first promise callback enqueues another timer — small additions that exercise every ordering rule the event loop applies, while keeping each line individually trivial to read.

console.log('Start');

setTimeout(() => {
  console.log('Timeout 1');
  Promise.resolve().then(() => console.log('Promise 2'));
}, 0);

Promise.resolve().then(() => {
  console.log('Promise 1');
  setTimeout(() => console.log('Timeout 3'), 0);
});

setTimeout(() => console.log('Timeout 2'), 0);

console.log('End');

// Console output:
// Start
// End
// Promise 1
// Timeout 1
// Promise 2
// Timeout 2
// Timeout 3

Queue entries in the trace below are labeled by the message their callback will log (so [Promise 1] means "the queued callback that will log Promise 1"). Names match registration order: Timeout 1 is the first timer registered, Promise 2 is the microtask scheduled later by Timeout 1's callback, and so on.

Three rules the trace makes explicit:

• Microtasks drain before any macrotask. Step 6 runs Promise 1 before either timer, even though both timers were scheduled before the promise callback ran.
• A macrotask that schedules a microtask interleaves. Step 7 runs Timeout 1 and enqueues Promise 2; step 8 runs Promise 2 before the next macrotask, not after. The event loop re-checks the microtask queue between every macrotask, which is why a single drain at the end of synchronous code is not enough to model behavior correctly.
• A microtask that schedules a macrotask appends to the queue. Step 6 runs Promise 1 and schedules Timeout 3; Timeout 3 then runs last, after both timers that were already in the macrotask queue. Microtasks cannot promote a macrotask to the front of the line.

Advanced examples

The examples below demonstrate event loop behaviors that commonly appear in production code and more advanced interview questions.

async/await scheduling

async/await is specified in terms of promise chaining. When execution reaches an await, the function is paused, its continuation is scheduled as a microtask on resolution of the awaited value, and control returns to the caller.

console.log('1');

async function run() {
  console.log('2');
  await Promise.resolve();
  console.log('3');
}

run();

setTimeout(() => console.log('4'), 0);

Promise.resolve().then(() => console.log('5'));

console.log('6');

// Output: 1, 2, 6, 3, 5, 4

Explanation:

1. 1 is logged from the first synchronous statement.
2. run() is invoked. Synchronous code in the function runs up to the await, logging 2.
3. The continuation of run() (everything after the await) is scheduled as a microtask. Control returns to the top-level script.
4. setTimeout schedules a macrotask.
5. Promise.resolve().then(...) schedules a microtask.
6. 6 is logged from the last synchronous statement.
7. The script completes and the microtask queue drains in FIFO order: run()'s continuation logs 3, then the .then callback logs 5.
8. The macrotask queue is then processed, logging 4.

The common misconception is that await blocks execution. It does not — the function is paused, but control returns immediately to the caller, and the continuation runs as a microtask once the awaited value settles.

Microtask starvation

Macrotasks run only once the microtask queue has fully drained. If microtasks continually schedule more microtasks, the macrotask queue never advances, which prevents rendering, user input handling, and timer callbacks from running.

let count = 0;

function scheduleMicrotask() {
  Promise.resolve().then(() => {
    count++;
    if (count < 5) scheduleMicrotask();
    console.log('microtask', count);
  });
}

setTimeout(() => console.log('macrotask fired'), 0);

scheduleMicrotask();

// Output: microtask 1, microtask 2, microtask 3, microtask 4, microtask 5, macrotask fired

With a bounded recursion depth, the macrotask eventually runs. An unbounded chain (for example if (true) instead of if (count < 5)) would prevent any macrotask from running and would block rendering in the browser.

To yield to the browser for rendering or input handling, a macrotask is required — for example setTimeout(fn, 0), MessageChannel, or scheduler.yield() in environments that support it. A microtask such as queueMicrotask or Promise.resolve().then does not yield.

Yielding the main thread to split long tasks

A synchronous block that runs longer than 50 ms is classified as a long task and blocks the browser from rendering, handling input, and processing timers for that duration. The fix is to break the work into chunks and yield to the event loop between chunks so that rendering and other macrotasks can run.

A loop that runs as one task — the entire computation blocks until it finishes:

function heavyWork() {
  let sum = 0;
  for (let i = 0; i < 1e8; i++) sum += i;
  return sum;
}

heavyWork(); // ~hundreds of ms; the page is unresponsive for the duration

The same work split across macrotasks via setTimeout:

function chunked(total, chunkSize, onDone) {
  let i = 0;
  let sum = 0;
  function tick() {
    const end = Math.min(i + chunkSize, total);
    while (i < end) {
      sum += i;
      i++;
    }
    if (i < total) {
      setTimeout(tick, 0);
    } else {
      onDone(sum);
    }
  }
  tick();
}

chunked(1e7, 1e6, (sum) => console.log('done', sum));

Between every chunk, the browser can paint a frame, dispatch input events, and run other macrotasks. The drawback is that the HTML specification clamps nested setTimeout delays to a minimum of 4 ms after 5 levels of recursion, which adds noticeable latency to long chunked computations.

MessageChannel schedules a macrotask without that clamp:

function yieldToMain() {
  return new Promise((resolve) => {
    const channel = new MessageChannel();
    channel.port1.onmessage = () => {
      channel.port1.close();
      channel.port2.close();
      resolve();
    };
    channel.port2.postMessage(null);
  });
}

async function chunked(total, chunkSize) {
  let i = 0;
  let sum = 0;
  while (i < total) {
    const end = Math.min(i + chunkSize, total);
    while (i < end) {
      sum += i;
      i++;
    }
    if (i < total) await yieldToMain();
  }
  return sum;
}

chunked(1e7, 1e6).then((sum) => console.log('done', sum));

postMessage enqueues a macrotask immediately without delay clamping, so the next chunk runs as soon as the browser has finished its render and any earlier pending tasks. React's scheduler used this pattern before scheduler.postTask was widely available. Production code should reuse a single MessageChannel instance instead of creating one per yield.

A comparison of the available yielding mechanisms:

Microtasks cannot be used to yield. They drain before rendering, which is the behavior the microtask-starvation example demonstrates.

queueMicrotask compared to Promise.resolve().then

Both schedule a microtask in the same FIFO queue and run at the same point in the event loop. They differ in how exceptions thrown inside the callback are surfaced.

queueMicrotask(() => {
  throw new Error('from queueMicrotask');
});

Promise.resolve().then(() => {
  throw new Error('from promise.then');
});

setTimeout(() => console.log('timeout ran'), 0);

• An exception thrown from a queueMicrotask callback is reported as an uncaught error and reaches window.onerror (in browsers) or uncaughtException (in Node).
• An exception thrown from a .then callback causes the resulting promise to reject, surfacing through unhandledrejection if no downstream .catch handles it.

queueMicrotask is appropriate when the callback is conceptually standalone and its errors should behave like any other thrown exception. .then is appropriate when the callback is part of a promise chain where errors are expected to be caught downstream.

Differences across runtimes

The event loop is specified differently in browsers, Node.js, and Web Workers. Code that relies on precise scheduling may behave differently across these environments.

Browsers

Specified in the HTML Living Standard:

• Each agent has its own event loop.
• The macrotask queue is partitioned into multiple task sources (timers, network I/O, UI events, postMessage, and others). FIFO order is guaranteed within a source but not across sources — the user agent may choose any non-empty source each turn.
• requestAnimationFrame callbacks run in a separate phase of the event loop, before the render step, rather than on the macrotask queue.
• A browser may update rendering between tasks, but it does not render in the middle of a microtask checkpoint. This is why a long microtask chain can delay rendering.

Where requestAnimationFrame and requestIdleCallback fit

At a rendering opportunity, the simplified order relevant to application code is:

1. Run a selected task, then perform a microtask checkpoint.
2. If the browser decides to update rendering, run eligible requestAnimationFrame callbacks.
3. Update style, layout, and paint as needed.
4. Run eligible idle callbacks when the user agent determines there is idle time.

requestAnimationFrame schedules work for the next paint, making it the right tool for visual updates synchronized with the display refresh rate (~ 16.7 ms per frame at 60 Hz). requestIdleCallback schedules work for the period after rendering and only if the browser has idle time, making it suitable for non-urgent background work.

console.log('1: sync');
queueMicrotask(() => console.log('2: microtask'));
setTimeout(() => console.log('3: macrotask'), 0);
requestAnimationFrame(() => console.log('4: rAF'));
typeof requestIdleCallback === 'function' &&
  requestIdleCallback(() => console.log('5: rIC'));
console.log('6: sync');

// Guaranteed prefix: 1, 6, 2
// Relative ordering of 3 and 4 depends on timing and the rendering opportunity.
// `5: rIC` may run later or be deferred under load

Do not depend on the timer and requestAnimationFrame callbacks having a fixed relative order: it varies with when the code runs and whether a rendering opportunity occurs. requestIdleCallback can also be deferred; use its timeout option when work must eventually run.

Node.js

Built on libuv, with additional phases beyond what the HTML spec describes:

• In CommonJS, Node drains the process.nextTick() queue before the promise microtask queue after the current operation. In ES modules, top-level scheduling can produce a different order because module evaluation already runs as a microtask.
• Event-loop work is divided into named phases such as timers, pending callbacks, poll (I/O), check (setImmediate), and close callbacks. Current Node versions run microtasks after callbacks, not merely once per complete loop iteration.
• At the top level of a script, the execution order of setImmediate(fn) and setTimeout(fn, 0) is not deterministic and depends on loop timing. Inside an I/O callback, setImmediate is guaranteed to run before setTimeout(fn, 0).

process.nextTick() is a Node-specific legacy API for most userland scheduling. Prefer queueMicrotask() unless the next-tick behavior is specifically required.

A comparison of the Node-specific scheduling primitives:

Observed ordering at the top of a script:

setImmediate(() => console.log('setImmediate'));
setTimeout(() => console.log('setTimeout'), 0);
Promise.resolve().then(() => console.log('promise'));
process.nextTick(() => console.log('nextTick'));

// CommonJS output begins:
// nextTick
// promise
// setTimeout (or setImmediate — order between these two is not guaranteed at the top level)
// setImmediate (or setTimeout)

Web Workers

• Each Worker has an independent event loop, with its own microtask and macrotask queues.
• Messages posted via postMessage are enqueued as macrotasks on the receiving Worker's event loop.
• No access to requestAnimationFrame or the DOM.

Common misconceptions

Several statements about the event loop appear frequently in explanations and in responses generated by large language models but are inaccurate:

1. "setTimeout(fn, 0) runs immediately after the current synchronous code." Microtasks drain first. A Promise.resolve().then(fn) scheduled after a setTimeout(fn, 0) still runs before the timer callback.
2. "await blocks the event loop." The await expression pauses the containing async function and returns control to the caller. The continuation is scheduled as a microtask and does not block other tasks.
3. "Microtasks run on a separate thread." A microtask runs on the same JavaScript agent and call stack as that agent's tasks. Workers are separate agents; microtasks are not automatically delegated to them.
4. "Promise.resolve() is synchronous when the promise is already resolved." The resolution is synchronous, but .then callbacks are always scheduled asynchronously as microtasks. This is a Promises/A+ requirement intended to guarantee consistent execution ordering.
5. "process.nextTick is a microtask." In Node.js, nextTick has its own queue that drains before the promise microtask queue.
6. "setTimeout(fn, 0) fires after 0 milliseconds." Both the HTML specification and Node.js clamp the minimum to a small non-zero value (4 ms for nested timers in browsers; 1 ms in Node). A delay of 0 is a lower bound, not a guarantee.

Further reading and resources

• The event loop — MDN
• HTML Living Standard: Event loops
• The Node.js Event Loop
• Event loop: microtasks and macrotasks
• "JavaScript Visualized - Event Loop, Web APIs, (Micro)task Queue" by Lydia Hallie
• "What the heck is the event loop anyway?" by Philip Roberts
• "In The Loop" by Jake Archibald

Exercises

console.log('A');
setTimeout(() => console.log('timer'), 0);
Promise.resolve().then(() => {
  console.log('microtask 1');
  queueMicrotask(() => console.log('microtask 2'));
});
console.log('B');

TL;DR

Event delegation is a technique in JavaScript where a single event listener is attached to a parent element instead of attaching event listeners to multiple child elements. When an event occurs on a child element, the event bubbles up the DOM tree, and the parent element's event listener handles the event based on the target element.

Event delegation provides the following benefits:

• Fewer listeners: A single listener can reduce listener bookkeeping and per-item closures for very large collections. Whether that produces a measurable performance improvement depends on the page and should be profiled.
• Simplified event handling: With event delegation, you only need to write the event handling logic once in the parent element's event listener. This makes the code more maintainable and easier to update.
• Dynamic element support: Event delegation automatically handles events for dynamically added or removed elements within the parent element. There's no need to manually attach or remove event listeners when the DOM structure changes.

However, do note that:

• It is important to identify the target element that triggered the event.
• Not every event bubbles. For example, focus/blur and mouseenter/mouseleave need capture-phase handling or bubbling alternatives such as focusin/focusout and mouseover/mouseout. Element scroll and resize generally need direct listeners.

One ancestor listener for many descendants

Delegation relies on bubbling: a stable ancestor receives descendant events and decides which matching child originated the interaction.

Because the listener belongs to the ancestor, newly added matching descendants work without separate listener registration.

Event delegation

Event delegation is a design pattern in JavaScript used to efficiently manage and handle events on multiple child elements by attaching a single event listener to a common ancestor element. This pattern is particularly valuable in scenarios where you have a large number of similar elements, such as list items, and want to optimize event handling.

How event delegation works

1. Attach a listener to a common ancestor: Instead of attaching individual event listeners to each child element, you attach a single event listener to a common ancestor element higher in the DOM hierarchy.
2. Event bubbling: When an event occurs on a child element, it bubbles up through the DOM tree to the common ancestor element. During this propagation, the event listener on the common ancestor can intercept and handle the event.
3. Determine the target: Within the event listener, you can inspect the event object to identify the actual target of the event (the child element that triggered the event). Use event.target to find which specific child element was interacted with. (event.currentTarget refers to the ancestor the listener is attached to, not the child that triggered the event.)
4. Perform action based on target: Based on the target element, you can perform the desired action or execute code specific to that element. This allows you to handle events for multiple child elements with a single event listener.

Benefits of event delegation

1. Fewer listeners: Event delegation reduces listener bookkeeping and can reduce memory use when dealing with a very large number of elements.
2. Dynamic elements: It works with dynamically added or removed child elements, as the common ancestor continues to listen for events on them.

Example

Here's a simple example:

// HTML:
// <ul id="item-list">
//   <li>Item 1</li>
//   <li>Item 2</li>
//   <li>Item 3</li>
// </ul>

const itemList = document.getElementById('item-list');

itemList.addEventListener('click', (event) => {
  if (event.target.tagName === 'LI') {
    console.log(`Clicked on ${event.target.textContent}`);
  }
});

In this example, a single click event listener is attached to the <ul> element. When a click event occurs on an <li> element, the event bubbles up to the <ul> element, where the event listener checks the target's tag name to identify whether a list item was clicked. It's crucial to check the identity of the event.target as there can be other kinds of elements in the DOM tree.

Use cases

Event delegation is commonly used in scenarios like:

Handling dynamic content in single-page applications

// HTML:
// <div id="button-container">
//   <button>Button 1</button>
//   <button>Button 2</button>
// </div>
// <button id="add-button">Add Button</button>

const buttonContainer = document.getElementById('button-container');
const addButton = document.getElementById('add-button');

buttonContainer.addEventListener('click', (event) => {
  if (event.target.tagName === 'BUTTON') {
    console.log(`Clicked on ${event.target.textContent}`);
  }
});

addButton.addEventListener('click', () => {
  const newButton = document.createElement('button');
  newButton.textContent = `Button ${buttonContainer.children.length + 1}`;
  buttonContainer.appendChild(newButton);
});

In this example, a click event listener is attached to the <div> container. When a new button is added dynamically and clicked, the event listener on the container handles the click event.

Simplifying code by avoiding the need to attach and remove event listeners for elements that change

// HTML:
// <form id="user-form">
//   <input type="text" name="username" placeholder="Username">
//   <input type="email" name="email" placeholder="Email">
//   <input type="password" name="password" placeholder="Password">
// </form>

const userForm = document.getElementById('user-form');

userForm.addEventListener('input', (event) => {
  const { name, value } = event.target;
  console.log(`Changed ${name}: ${value}`);
});

In this example, a single input event listener is attached to the form element. It can respond to input changes for all child input elements, simplifying the code by eliminating the need for individual listeners on each <input> element.

More real-world delegation patterns

Beyond the simple list-item example, three patterns show up constantly in production code.

Form-wide delegated change handler

A single change or input listener on the form catches every input update, which is useful for autosave, dirty-tracking, and validation:

// HTML: <form id="profile-form"> with many inputs/selects/textareas inside

const form = document.getElementById('profile-form');

form.addEventListener('input', (event) => {
  // Works for any <input>, <select>, or <textarea> the form contains,
  // even ones added later by the user.
  const field = event.target;
  console.log(`${field.name} changed to ${field.value}`);
  scheduleAutosave(field.name, field.value);
});

No matter how many fields the form has, or whether new fields are appended dynamically, only one listener is needed.

Data-table row actions

Modern data-table UIs commonly use a single click handler on the table that reads data-action from the clicked element to know what to do. This is delegation plus the data-attribute pattern:

// HTML rows look like:
// <tr>
//   <td>...</td>
//   <td>
//     <button data-action="edit" data-id="42">Edit</button>
//     <button data-action="delete" data-id="42">Delete</button>
//   </td>
// </tr>

document.querySelector('table').addEventListener('click', (event) => {
  const button = event.target.closest('[data-action]');
  if (!button) {
    return;
  }
  const { action, id } = button.dataset;
  if (action === 'edit') {
    openEditor(id);
  }
  if (action === 'delete') {
    confirmDelete(id);
  }
});

event.target.closest() is the workhorse here. It walks up from the click target to the nearest matching ancestor, which makes the handler robust against inner spans, icons, and styling wrappers.

Click-to-edit cells

A spreadsheet-style cell editor uses delegation to promote whichever cell was clicked into an editable input, without attaching one listener per cell:

document.querySelector('table').addEventListener('click', (event) => {
  const cell = event.target.closest('td.editable');
  if (!cell || cell.querySelector('input')) {
    return; // already editing
  }

  const original = cell.textContent;
  const input = document.createElement('input');
  input.value = original;
  cell.textContent = '';
  cell.appendChild(input);
  input.focus();

  input.addEventListener('blur', () => {
    cell.textContent = input.value;
    if (input.value !== original) saveCell(cell.dataset.id, input.value);
  });
});

Delegating non-bubbling events

The TL;DR notes that focus, blur, scroll, mouseenter, mouseleave, and resize do not bubble, so the obvious delegation pattern (one listener on the parent) does not work for them. Two solid workarounds:

Use the capture phase

Pass a third argument of true (or { capture: true }) to listen during the capture phase. The event is visible to ancestors on the way down to the target, even if it does not bubble back up:

document.body.innerHTML = `
  <div id="form">
    <input id="a" placeholder="A">
    <input id="b" placeholder="B">
  </div>
`;

document.getElementById('form').addEventListener(
  'focus',
  (event) => {
    console.log('focused:', event.target.id);
  },
  true, // capture: catch focus before it stops at the input
);

// In a real page, focus events fire automatically when the user clicks or
// tabs into an input. Here we dispatch them by hand so the demo prints the
// same sequence in this playground.
['a', 'b'].forEach((id) => {
  document.getElementById(id).dispatchEvent(new FocusEvent('focus'));
});
// Logs: focused: a, then focused: b

Use the bubbling siblings: focusin and focusout

focus does not bubble, but focusin does. The same is true for blur and focusout. The pointer events have similar pairs: mouseover and mouseout bubble, while mouseenter and mouseleave do not (note that mouseover and mouseout also fire when the pointer crosses descendant boundaries, so the semantics are slightly different). The bubbling variants exist specifically to support delegation:

document.body.innerHTML = `
  <form id="form">
    <input id="a" placeholder="A">
    <input id="b" placeholder="B">
  </form>
`;

const form = document.getElementById('form');
form.addEventListener('focusin', (event) =>
  console.log('focusin:', event.target.id),
);
form.addEventListener('focusout', (event) =>
  console.log('focusout:', event.target.id),
);

// In a real page, focusin and focusout fire automatically when the user
// moves between inputs. Here we dispatch them by hand to simulate the user
// moving focus from input A to input B inside this playground.
const a = document.getElementById('a');
const b = document.getElementById('b');

[
  [a, 'focusin'], // focusin: a
  [a, 'focusout'], // focusout: a
  [b, 'focusin'], // focusin: b
].forEach(([el, type]) => {
  el.dispatchEvent(new FocusEvent(type, { bubbles: true }));
});

For scroll, the bubbling-sibling approach does not exist. Capture-phase delegation technically works (capture-phase listeners on ancestors do receive scroll events from descendants), but it is rarely a good idea: scroll events fire many times per second, you would receive them for every nested scroller in the subtree, and there is no event.target filtering that beats just attaching a listener directly to the scrollable element. Use one direct listener instead. (window scroll has nothing higher to delegate to anyway.)

Performance: when delegation actually helps

The common claim is "delegation is faster because there are fewer listeners." That is partly true but often overstated.

• Listener count is often not the bottleneck. Modern browsers handle many listeners efficiently, so measure the actual page rather than relying on a fixed listener-count rule.
• Memory is the meaningful win. Each direct listener creates a closure that holds references to its enclosing scope. With 10,000 rows, that is 10,000 closures kept alive, which can become noticeable. One delegated listener is one closure.
• Dynamic content is the structural win. With direct listeners, you have to attach (and detach) listeners on every DOM mutation, which is easy to leak. Delegation just works for elements added later, and that is the main reason most code uses it.
• Delegation is not always faster at runtime. A delegated handler runs event.target.closest(...) on every event, which is cheap but not free. For a small fixed number of elements with stable handlers, attaching directly is fine and arguably cleaner.

Use delegation for memory, dynamic content, and code simplicity, not because direct listeners are inherently slow.

Pitfalls

Event delegation comes with several pitfalls:

• Incorrect target handling. Use event.target.closest(selector) rather than checking event.target.tagName directly. Clicks on inner elements (icons, spans) will otherwise miss the match.
• Not all events bubble. focus, blur, scroll, mouseenter, mouseleave, and resize do not bubble. Use the capture phase or the bubbling alternatives (focusin, focusout, mouseover, mouseout) shown above.
• stopPropagation() inside the tree breaks delegation. If a child handler calls event.stopPropagation(), the delegated handler at the ancestor never fires. This is a common source of "my handler doesn't run" bugs.
• Event overhead. Complex routing logic inside the root listener can become hard to maintain. Use small dispatch tables ({ edit: ..., delete: ... }) rather than long if/else chains.

Event delegation in JavaScript frameworks

For many event types, React installs native listeners on the React root and dispatches synthetic events through the component tree. Some event types are handled differently because they do not delegate normally, so this is an implementation detail rather than a guarantee that every React handler maps to one root listener.

When an event occurs, React's event listener captures it and determines which React component rendered the target element based on its internal bookkeeping. React then dispatches the event to the appropriate component's event handler by calling the handler function with a synthetic event object. This synthetic event object wraps the native browser event, providing a consistent interface across different browsers and capturing information about the event.

This lets React provide a consistent event API and centralize much of its event dispatch. Application code should still choose delegation based on the DOM behavior it needs rather than assuming it is always faster.

Further reading

• MDN Web Docs on Event Delegation
• JavaScript.info - Event Delegation

Exercises

TL;DR

There's no simple explanation for this; it is one of the most confusing concepts in JavaScript because its behavior differs from many other programming languages. The one-liner explanation of the this keyword is that it is a dynamic reference to the context in which a function is executed.

A longer explanation is that this follows these rules:

1. If the new keyword is used when calling the function, meaning the function was used as a function constructor, the this inside the function is the newly-created object instance.
2. If this is used in a class constructor, the this inside the constructor is the newly-created object instance.
3. If apply(), call(), or bind() is used to call/create a function, this inside the function is the object that is passed in as the argument.
4. If a function is called as a method (e.g. obj.method()) — this is the object that the function is a property of.
5. If a function is invoked as a free function invocation, meaning it was invoked without any of the conditions present above, this is the global object. In the browser, the global object is the window object. If in strict mode ('use strict';), this will be undefined instead of the global object.
6. If multiple of the above rules apply, the rule that is higher wins and will set the this value.
7. If the function is an ES2015 arrow function, it ignores all the rules above and receives the this value of its surrounding scope at the time it is created.

For an in-depth explanation, do check out Arnav Aggrawal's article on Medium.

Resolve this from the function and call form

For ordinary functions, this is usually selected at invocation time; arrow functions are the major lexical exception.

Copying a method into a variable changes its call form and can therefore change this.

this keyword

In JavaScript, this is a keyword that refers to the current execution context of a function or script. It's a fundamental concept in JavaScript, and understanding how this works is crucial for building maintainable applications.

Used globally

At the top level of a classic browser script, this refers to window. At the top level of an ES module, it is undefined. Node.js also depends on the module system: top-level this in CommonJS is module.exports, not globalThis, while it is undefined in an ES module.

console.log(this); // In a browser, this will log the window object (for non-strict mode).

Within a regular function call

When a function is called in the global context or as a standalone function, this refers to the global object (in non-strict mode) or undefined (in strict mode).

function showThis() {
  console.log(this);
}

showThis(); // In non-strict mode: Window (global object). In strict mode: undefined.

Within a method call

When a function is called as a method of an object, this refers to the object that the method is called on.

const obj = {
  name: 'John',
  showThis: function () {
    console.log(this);
  },
};

obj.showThis(); // { name: 'John', showThis: ƒ }

Note that if you do the following, it is as good as a regular function call and not a method call. this has lost its context and no longer points to obj.

const obj = {
  name: 'John',
  showThis: function () {
    console.log(this);
  },
};

const showThisStandalone = obj.showThis;
showThisStandalone(); // In non-strict mode: Window (global object). In strict mode: undefined.

Within a function constructor

When a function is used as a constructor (called with the new keyword), this refers to the newly-created instance. In the following example, this refers to the Person object being created, and the name property is set on that object.

function Person(name) {
  this.name = name;
}

const person = new Person('John');
console.log(person.name); // "John"

Within class constructor and methods

In ES2015 classes, this behaves as it does in object methods. It refers to the instance of the class.

class Person {
  constructor(name) {
    this.name = name;
  }

  showThis() {
    console.log(this);
  }
}

const person = new Person('John');
person.showThis(); // Person {name: 'John'}

const showThisStandalone = person.showThis;
showThisStandalone(); // `undefined` because in JavaScript class bodies, all methods are strict mode by default, even if you don't add 'use strict'

Explicitly binding this

You can use bind(), call(), or apply() to explicitly set the value of this for a function.

The call() and apply() methods allow you to explicitly set the value of this when calling the function.

function showThis() {
  console.log(this);
}
const obj = { name: 'John' };

showThis.call(obj); // { name: 'John' }
showThis.apply(obj); // { name: 'John' }

The bind() method creates a new function with this bound to the specified value.

function showThis() {
  console.log(this);
}
const obj = { name: 'John' };

const boundFunc = showThis.bind(obj);
boundFunc(); // { name: 'John' }

Within arrow functions

Arrow functions do not have their own this context. Instead, this is lexically scoped, which means it inherits the this value from its surrounding scope at the time the arrow function is defined.

In this example, this refers to the global object (window or global), because the arrow function is not bound to the person object.

const person = {
  firstName: 'John',
  sayHello: () => {
    console.log(`Hello, my name is ${this.firstName}!`);
  },
};

person.sayHello(); // "Hello, my name is undefined!"

In the following example, the this in the arrow function will be the this value of its enclosing context, so it depends on how showThis() is called.

const obj = {
  name: 'John',
  showThis: function () {
    const arrowFunc = () => {
      console.log(this);
    };
    arrowFunc();
  },
};

obj.showThis(); // { name: 'John', showThis: ƒ }

const showThisStandalone = obj.showThis;
showThisStandalone(); // In non-strict mode: Window (global object). In strict mode: undefined.

Therefore, the this value in arrow functions cannot be set by bind(), apply() or call() methods, nor does it point to the current object in object methods.

const obj = {
  name: 'Alice',
  regularFunction: function () {
    console.log('Regular function:', this.name);
  },
  arrowFunction: () => {
    console.log('Arrow function:', this.name);
  },
};

const anotherObj = {
  name: 'Bob',
};

// Using call/apply/bind with a regular function
obj.regularFunction.call(anotherObj); // Regular function: Bob
obj.regularFunction.apply(anotherObj); // Regular function: Bob
const boundRegularFunction = obj.regularFunction.bind(anotherObj);
boundRegularFunction(); // Regular function: Bob

// call/apply/bind cannot replace an arrow function's lexically captured `this`.
obj.arrowFunction.call(anotherObj); // Uses the surrounding scope's `this`.
obj.arrowFunction.apply(anotherObj); // Uses the surrounding scope's `this`.
const boundArrowFunction = obj.arrowFunction.bind(anotherObj);
boundArrowFunction(); // Still uses the surrounding scope's `this`.

Within event handlers

When a regular function is called as a DOM event listener, this refers to the element on which the listener was registered (event.currentTarget). It is not necessarily the element where the event originated (event.target). In this example both values are the same button.

<button id="my-button" onclick="console.log(this)">Click me</button>
<!-- Logs the button element -->

When setting an event handler using JavaScript, this also refers to the element that received the event.

document.getElementById('my-button').addEventListener('click', function () {
  console.log(this); // Logs the button element
});

As mentioned above, ES2015 introduced arrow functions, which use the enclosing lexical scope. This is usually convenient, but it does prevent the caller from defining the this context via .call/.apply/.bind. One of the consequences is that DOM event handlers will not properly bind this in your event handler functions if you define the callback parameters to .addEventListener() using arrow functions.

document.getElementById('my-button').addEventListener('click', () => {
  console.log(this); // Lexically captured `this`, not the button element.
});

In summary, this in JavaScript refers to the current execution context of a function or script, and its value can change depending on the context in which it is used. Understanding how this works is essential for building maintainable JavaScript applications.

Further reading

• this - JavaScript | MDN
• The Simple Rules to this in JavaScript
• Gentle Explanation of this in JavaScript

Exercises

'use strict';

const counter = {
  value: 7,
  read() {
    return this?.value;
  },
};

const read = counter.read;
console.log(counter.read(), read());

TL;DR

Cookies, localStorage, and sessionStorage all store data in the browser, but they differ in lifetime, scope, server interaction, and security controls. localStorage and sessionStorage implement the Web Storage API.

• Cookies: Small values that the browser sends with matching HTTP requests. They can be session or persistent cookies and support controls such as HttpOnly, Secure, and SameSite.
• localStorage: Origin-scoped string storage that persists until it is cleared and is shared by same-origin tabs and windows.
• sessionStorage: Origin- and tab-scoped string storage for a page session. It survives reloads but is normally cleared when the tab or window closes.

Here's a table summarizing the 3 client storage mechanisms.

Scope and data flow

The mechanisms differ most in who can access the data, how long it lasts, and whether it travels with HTTP requests.

Web Storage is never attached automatically to requests; an HttpOnly cookie is intentionally unavailable to JavaScript.

Storage on the web

Cookies, localStorage, and sessionStorage are browser storage mechanisms. Client storage is useful for state such as themes, personalized layouts, draft form data, and identifiers needed by a server session. Sensitive authentication credentials require a threat-model-specific design; they should not be placed in Web Storage by default.

These client-side storage mechanisms have the following common properties:

• Client-side JavaScript can read and modify the values, except for HttpOnly cookies.
• Key-value based storage.
• They are only able to store values as strings. Non-strings will have to be serialized into a string (e.g. JSON.stringify()) in order to be stored.

Use cases for each storage mechanism

Since cookies have a relatively low maximum size, it is not advisable to store all your client-side data within cookies. The distinguishing properties about cookies are that cookies are sent to the server on every HTTP request so the low maximum size is a feature that prevents your HTTP requests from being too large due to cookies. Automatic expiry of cookies is a useful feature as well.

With that in mind, cookies suit small values that the server needs, such as opaque session identifiers, analytics identifiers, consent choices, or language preferences used during server rendering. Sensitive cookies can benefit from HttpOnly, Secure, and SameSite; Expires or Max-Age controls persistence. The server must still validate and authorize every request.

localStorage and sessionStorage both implement the Web Storage API interface. Their quota is browser-dependent and can be exceeded, so applications should handle QuotaExceededError. Values stored in Web Storage are not automatically sent with HTTP requests.

While you can manually include values from Web Storage when making AJAX/fetch() requests, the browser does not include them in the initial request / first load of the page. Hence Web Storage should not be used to store data that is relied on by the server for the initial rendering of the page if server-side rendering is being used (typically authentication/authorization-related information). localStorage is most suitable for user preferences data that do not expire, like themes and layouts (if it is not important for the server to render the final layout). sessionStorage is most suitable for temporary data that only needs to be accessible within the current browsing session, such as form data (useful to preserve data during accidental reloads).

The following sections dive deeper into each client storage mechanism.

Cookies

Cookies are used to store small pieces of data on the client side that can be sent back to the server with every HTTP request.

• Storage capacity: Limited to around 4 KB per cookie. Browsers also limit how many cookies can be stored per domain.
• Lifespan: Cookies can have a specific expiration date set using the Expires or Max-Age attributes. Without one, they are session cookies, although browsers may restore session cookies as part of session restore.
• Access: Cookies are domain-specific and can be shared across different pages and subdomains within the same domain.
• Security: Cookies can be marked as HttpOnly to prevent access from JavaScript, reducing the risk of XSS attacks. They can also be secured with the Secure flag to ensure they are sent only when HTTPS is used.

// Set a non-sensitive preference cookie with an expiry.
document.cookie =
  'theme=dark; expires=Fri, 31 Dec 2100 23:59:59 GMT; path=/; SameSite=Lax; Secure';

// Read all cookies. There's no way to read specific cookies using `document.cookie`.
// You have to parse the string yourself.
console.log(document.cookie); // theme=dark

// Delete the cookie with the name/key `theme` by setting an
// expiry date in the past. The value doesn't matter.
document.cookie = 'theme=; expires=Thu, 01 Jan 1970 00:00:00 GMT; path=/';