JavaScript Interview Questions

TL;DR

Hoisting is a JavaScript mechanism where variable and function declarations are moved ("hoisted") to the top of their containing scope during the compile phase.

• Variable declarations (var): Declarations are hoisted, but not initializations. The value of the variable is undefined if accessed before initialization.
• Variable declarations (let and const): Declarations are hoisted, but not initialized. Accessing them results in ReferenceError until the actual declaration is encountered.
• Function expressions (var): Declarations are hoisted, but not initializations. The value of the variable is undefined if accessed before initialization.
• Function declarations (function): Both declaration and definition are fully hoisted.
• Class declarations (class): Declarations are hoisted, but not initialized. Accessing them results in ReferenceError until the actual declaration is encountered.
• Import declarations (import): Declarations are hoisted, and side effects of importing the module are executed before the rest of the code.

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

Hoisting

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

Variables declared with the var keyword have their declaration "moved" up to the top of their containing scope during compilation, which we refer to as hoisting.

Only the declaration is hoisted; the initialization/assignment (if there is one) will stay where it is. Note that the declaration is not actually moved – the JavaScript engine parses the declarations during compilation and becomes aware of variables and their scopes, but it is easier to understand this behavior by visualizing the declarations as being "hoisted" to the top of their scope.

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

Variables declared via let, const, and class are hoisted as well. However, unlike var and function, they are not initialized and accessing them before the declaration will result in a ReferenceError exception. The variable is in a "temporal dead zone" from the start of the block until the declaration is processed.

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, only the variable declaration is hoisted — the function body is not.

console.log(bar); // undefined
bar(); // Uncaught 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, function declarations have both the declaration and definition hoisted, thus they can be called even before they are declared.

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'. Function declarations are fully hoisted — both the identifier binding and the function body are available from the top of the scope.
• expressed() throws TypeError: expressed is not a function. The var expressed binding is hoisted and initialized 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. The declaration is hoisted past if, for, while, and plain block statements to the containing function or module 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.

Class declarations are hoisted — the binding is created at the top of the enclosing block — but they remain 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. Both var inner and the function inner declaration are hoisted to the top of outer.
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 declarations are hoisted. They remain in the Temporal Dead Zone until the declaration is evaluated, which is observably different from not being hoisted at all — 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 are hoisted. They differ in initialization: var is initialized to undefined at hoist time, while let and const remain uninitialized in the TDZ until their declaration is 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. Both are hoisted, but only the binding. In var fn = function () {}, the var fn declaration is hoisted and initialized to undefined. In let fn = function () {}, the binding is hoisted but remains in the TDZ. The function body is never hoisted for expressions.

Further reading

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

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:

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 'baz' 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

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.

There's one final value-comparison operation within JavaScript: the Object.is() static method. The only difference between Object.is() and === is how they treat signed zeros and NaN values. The === operator (and the == operator) treats the number values -0 and +0 as equal, but treats NaN as not equal to each other.

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

TL;DR

The event loop is a concept within the JavaScript runtime environment regarding how asynchronous operations are executed within JavaScript engines. It works as such:

1. The JavaScript engine starts executing scripts, placing synchronous operations on the call stack.
2. When an asynchronous operation is encountered (e.g., setTimeout(), HTTP request), it is offloaded to the respective Web API or Node.js API to handle the operation in the background.
3. Once the asynchronous operation completes, its callback function is placed in the respective queues – task queues (also known as macrotask queues / callback queues) or microtask queues. We will refer to "task queue" as "macrotask queue" from here on to better differentiate from the microtask queue.
4. The event loop continuously monitors the call stack and executes items on the call stack. If/when the call stack is empty:
   1. Microtask queue is processed. Microtasks include promise callbacks (then, catch, finally), await continuations, MutationObserver callbacks, and calls to queueMicrotask(). The event loop takes the first callback from the microtask queue and pushes it to the call stack for execution. This repeats until the microtask queue is empty.
   2. Macrotask queue is processed. Macrotasks include web APIs like setTimeout(), HTTP requests, user interface event handlers like clicks, scrolls, etc. The event loop dequeues the first callback from the macrotask queue and pushes it onto the call stack for execution. However, after a macrotask queue callback is processed, the event loop does not proceed with the next macrotask yet! The event loop first checks the microtask queue. Checking the microtask queue is necessary as microtasks have higher priority than macrotask queue callbacks. The macrotask queue callback that was just executed could have added more microtasks!
      1. If the microtask queue is non-empty, process them as per the previous step.
      2. If the microtask queue is empty, the next macrotask queue callback is processed. This repeats until the macrotask queue is empty.
5. This process continues indefinitely, allowing the JavaScript engine to handle both synchronous and asynchronous operations efficiently without blocking the call stack.

Event loop in JavaScript

The event loop is the mechanism that lets JavaScript handle asynchronous operations without blocking its single-threaded execution.

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

Asynchronous operations like setTimeout(), HTTP requests, file I/O, etc., are handled by Web APIs (in the browser) or C++ APIs (in Node.js). These APIs are not part of the JavaScript engine and run on separate threads, allowing them to execute concurrently without blocking the call stack.

Task queue / Macrotask queue / Callback queue

The macrotask queue (also called the task queue, callback queue, or event queue) holds callbacks waiting to run when the call stack and microtask queue are empty.

Microtasks queue

The microtask queue holds higher-priority callbacks that drain after the call stack empties and between every macrotask.

Event loop order

1. The JavaScript engine starts executing scripts, placing synchronous operations on the call stack.
2. When an asynchronous operation is encountered (e.g., setTimeout(), HTTP request), it is offloaded to the respective Web API or Node.js API to handle the operation in the background.
3. Once the asynchronous operation completes, its callback function is placed in the respective queues – task queues (also known as macrotask queues / callback queues) or microtask queues. We will refer to "task queue" as "macrotask queue" from here on to better differentiate from the microtask queue.
4. The event loop continuously monitors the call stack and executes items on the call stack. If/when the call stack is empty:
   1. Microtask queue is processed. The event loop takes the first callback from the microtask queue and pushes it to the call stack for execution. This repeats until the microtask queue is empty.
   2. Macrotask queue is processed. The event loop dequeues the first callback from the macrotask queue and pushes it onto the call stack for execution. However, after a macrotask queue callback is processed, the event loop does not proceed with the next macrotask yet! The event loop first checks the microtask queue. Checking the microtask queue is necessary as microtasks have higher priority than macrotask queue callbacks. The macrotask queue callback that was just executed could have added more microtasks!
      1. If the microtask queue is non-empty, process them as per the previous step.
      2. If the microtask queue is empty, the next macrotask queue callback is processed. This repeats until the macrotask queue is empty.
5. This process continues indefinitely, allowing the JavaScript engine to handle both synchronous and asynchronous operations efficiently without blocking the call stack.

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 = () => 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.
• Rendering (style, layout, paint) occurs between macrotasks, not between microtasks. This is why a long microtask chain can freeze the UI.

Where requestAnimationFrame and requestIdleCallback fit

Within a single iteration of the event loop, the browser visits these phases in order:

1. Run one task from a macrotask queue source.
2. Drain the microtask queue (including any microtasks scheduled by step 1).
3. If a render is due this turn, run all requestAnimationFrame callbacks queued for the next frame.
4. Style, layout, and paint.
5. During any remaining idle time before the next frame deadline, run requestIdleCallback callbacks.

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');

// Typical output: 1, 6, 2, 3, 4, 5
// `5: rIC` may run later or be deferred under load

setTimeout(fn, 0) typically logs before the requestAnimationFrame callback because the timer's macrotask is dispatched on the next event loop turn, while rAF waits for the next paint (often a few milliseconds later at typical refresh rates). requestIdleCallback runs only after the browser finishes rendering, which is why it appears last and is the only callback in this example that may be deferred.

Node.js

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

• process.nextTick() has a higher-priority queue that drains before the promise microtask queue on every phase transition.
• Macrotasks are divided into named phases: timers, pending callbacks, idle/prepare, poll (I/O), check (setImmediate), and close callbacks. Phases run in order, and microtasks together with nextTick drain between each.
• 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).

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'));

// Output:
// 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." JavaScript execution is single-threaded. Microtasks run on the main thread, interleaved with macrotasks under the event loop's scheduling rules.
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 (4ms for nested timers in browsers; 1ms 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

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:

• Improved performance: Attaching a single event listener is more efficient than attaching multiple event listeners to individual elements, especially for large or dynamic lists. This reduces memory usage and improves overall performance.
• 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 all events can be delegated because they are not bubbled. Non-bubbling events include: focus, blur, scroll, mouseenter, mouseleave, resize, etc.

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). You can use properties like event.target or event.currentTarget to determine which specific child element was interacted with.
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. Efficiency: Event delegation reduces the number of event listeners, improving memory usage and performance, especially when dealing with a large number of elements.
2. Dynamic elements: It works seamlessly 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 rarely the bottleneck. On modern browsers, attaching 100 vs 10,000 click listeners is still sub-millisecond. Adding listeners is almost free, and dispatching a click is fast either way.
• 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

In React, event handlers are attached to the React root's DOM container into which the React tree is rendered. Even though onClick is added to child elements, the actual event listeners are attached to the root DOM node, leveraging event delegation to optimize event handling and improve performance.

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.

By using event delegation, React avoids attaching individual event handlers to each component instance, which would create significant overhead, especially for large component trees. Instead, React leverages the browser's native event bubbling mechanism to capture events at the root and distribute them to the appropriate components.

Further reading

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

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.

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 robust and maintainable applications.

Used globally

In the global scope, this refers to the global object, which is the window object in a web browser or the global object in a Node.js environment.

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

// Using call/apply/bind with an arrow function, `this` refers to the global scope and cannot be modified.
obj.arrowFunction.call(anotherObj); // Arrow function: window/undefined (depending if strict mode)
obj.arrowFunction.apply(anotherObj); // Arrow function: window/undefined (depending if strict mode)
const boundArrowFunction = obj.arrowFunction.bind(anotherObj);
boundArrowFunction(); // Arrow function: window/undefined (depending if strict mode)

Within event handlers

When a function is called as a DOM event handler, this refers to the element that triggered the event. In this example, this refers to the <button> element that was clicked.

<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); // Window / undefined (depending on whether strict mode) instead of 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 robust and maintainable JavaScript applications.

Further reading

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

TL;DR

All of the following are mechanisms of storing data on the client, the user's browser in this case. localStorage and sessionStorage both implement the Web Storage API interface.

• Cookies: Suitable for server-client communication, small storage capacity, can be persistent or session-based, domain-specific. Sent to the server on every request.
• localStorage: Suitable for long-term storage, data persists even after the browser is closed, accessible across all tabs and windows of the same origin, highest storage capacity among the three.
• sessionStorage: Suitable for temporary data within a single page session, data is cleared when the tab or window is closed, has a higher storage capacity compared to cookies.

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

Storage on the web

Cookies, localStorage, and sessionStorage, are all storage mechanisms on the client (web browser). It is useful to store data on the client for client-only state like access tokens, themes, personalized layouts, so that users can have a consistent experience on a website across tabs and usage sessions.

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

• This means the clients 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, the best kind of data to store within cookies is small pieces of data that need to be transmitted to the server, such as auth tokens, session IDs, analytics tracking IDs, GDPR cookie consent, language preferences that are important for authentication, authorization, and rendering on the server. These values are sometimes sensitive and can benefit from the HttpOnly, Secure, and Expires/Max-Age capabilities that cookies provide.

localStorage and sessionStorage both implement the Web Storage API interface. Web Storage has a generous total capacity of 5MB, so storage size is usually not a concern. The key difference is that values stored in Web Storage are not automatically sent along 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 4KB for all cookies.
• Lifespan: Cookies can have a specific expiration date set using the Expires or Max-Age attributes. If no expiration date is set, the cookie is deleted when the browser is closed (session cookie).
• 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 cookie for the name/key `auth_token` with an expiry.
document.cookie =
  'auth_token=abc123def; expires=Fri, 31 Dec 2024 23:59:59 GMT; path=/';

// 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); // auth_token=abc123def

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

It is a pain to read/write to cookies. document.cookie returns a single string containing all the key/value pairs delimited by ; and you have to parse the string yourself. The js-cookie npm library provides a simple and lightweight API for reading/writing cookies in JavaScript.

A modern native way of accessing cookies is via the Cookie Store API which is only available on HTTPS pages.

// Set a cookie. More options are available too.
cookieStore.set('auth_token', 'abc123def');

// Async method to access a single cookie and do something with it.
cookieStore.get('auth_token').then(...);

// Async method to get all cookies.
cookieStore.getAll().then(...);

// Async method to delete a single cookie.
cookieStore.delete('auth_token').then(() =>
  console.log('Cookie deleted')
);

The CookieStore API is relatively new and may not be supported in all browsers (supported in latest Chrome and Edge as of June 2024). Refer to caniuse.com for the latest compatibility.

localStorage

localStorage is used for storing data that persists even after the browser is closed and reopened. It is designed for long-term storage of data.

• Storage capacity: Typically around 5MB per origin (varies by browser).
• Lifespan: Data in localStorage persists until explicitly deleted by the user or the application.
• Access: Data is accessible within all tabs and windows of the same origin.
• Security: All JavaScript on the page has access to values within localStorage.

// Set a value in localStorage.
localStorage.setItem('key', 'value');

// Get a value from localStorage.
console.log(localStorage.getItem('key'));

// Remove a value from localStorage.
localStorage.removeItem('key');

// Clear all data in localStorage.
localStorage.clear();

sessionStorage

sessionStorage is used to store data for the duration of the page session. It is designed for temporary storage of data.

• Storage Capacity: Typically around 5MB per origin (varies by browser).
• Lifespan: Data in sessionStorage is cleared when the page session ends (i.e., when the browser or tab is closed). Reloading the page does not destroy data within sessionStorage.
• Access: Data is accessible only within the current tab (or browsing context). Different tabs share different sessionStorage objects even if they belong to the same browser window. In this context, window refers to a browser window that can contain multiple tabs.
• Security: All JavaScript on the same page has access to values within sessionStorage for that page.

// Set a value in sessionStorage.
sessionStorage.setItem('key', 'value');

// Get a value from sessionStorage.
console.log(sessionStorage.getItem('key'));

// Remove a value from sessionStorage.
sessionStorage.removeItem('key');

// Clear all data in sessionStorage.
sessionStorage.clear();

Security

A side-by-side feature comparison hides the most important practical difference between these three: how each one behaves under XSS.

The practical takeaways:

• Auth and session tokens belong in HttpOnly; Secure; SameSite=Lax cookies, not in localStorage. Any XSS bug in any script on the origin can read everything in localStorage. An HttpOnly cookie cannot be read by JavaScript at all, so the attacker would have to make requests through the user's browser, which CSRF defenses (SameSite, double-submit tokens) are designed to block.
• CSRF vs XSS is the trade-off. Cookies need CSRF protection; localStorage tokens (with the Authorization-header pattern) do not. The cookie plus SameSite=Lax combination is generally considered safer because it survives XSS, and SameSite=Lax blocks the most common CSRF cases by default.
• localStorage is fine for non-sensitive client state: theme preferences, layout settings, draft text, recently viewed items.

Real-world set, get, and remove

The three APIs look superficially similar but have meaningfully different ergonomics. Here is the same operation in each:

// localStorage: synchronous, string-only
localStorage.setItem('user', JSON.stringify({ id: 1, name: 'Ada' }));
const user = JSON.parse(localStorage.getItem('user') ?? 'null');
localStorage.removeItem('user');

// sessionStorage: same shape, scoped to the tab
sessionStorage.setItem('draft', 'hello');
const draft = sessionStorage.getItem('draft');
sessionStorage.removeItem('draft');

// Cookie: modern async API (where supported)
await cookieStore.set({
  name: 'session',
  value: 'abc123',
  sameSite: 'Lax',
  secure: true,
  expires: Date.now() + 7 * 24 * 60 * 60 * 1000,
});
const session = await cookieStore.get('session');
await cookieStore.delete('session');

// Cookie: legacy `document.cookie` API (universally supported)
document.cookie =
  'session=abc123; Path=/; Max-Age=604800; SameSite=Lax; Secure';
// Reading a specific cookie still requires parsing the string yourself:
const value = document.cookie
  .split('; ')
  .find((row) => row.startsWith('session='))
  ?.split('=')[1];