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 variable declarations in JavaScript code.

Variables declared or initialized with the var keyword will 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 seen in action here as even though foo is declared and initialized after the first console.log(), the first console.log() prints the value of foo as 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

Function expressions are functions written in the form of variable declarations. Since they are also declared using var, only the variable declaration is hoisted.

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

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

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 generators (function*), async functions (async function), and async function generators (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 var keyword will have the value of undefined where variables created using let and const keywords will be marked as <value unavailable>. Thus, accessing them will cause a ReferenceError preventing you to access them before initialization.

In ECMAScript specifications 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.

Modern practices

In practice, modern code bases 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: This rule will warn when it encounters a reference to an identifier that has not yet been declared.
• no-undef: This rule will warn when it encounters a reference to an identifier that has not yet been declared.

Further reading

• Hoisting | 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 quz 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

let and const differ in that 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 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. The == operator will compare for equality after doing any necessary type conversions. The === operator will not do type conversion, so if two values are not the same type === will simply return false.

Equality operator (==)

The == operator checks for equality between two values but performs type coercion if the values are of different types. This means that JavaScript will attempt to convert the values to a common type before making the comparison.

console.log(42 == '42'); // true
console.log(0 == false); // true
console.log(null == undefined); // true
console.log([] == false); // true
console.log('' == false); // true

In these examples, JavaScript converts the operands to the same type before making the comparison. For example, 42 == '42' is true because the string '42' is converted to the number 42 before comparison.

However, when using ==, unintuitive results can happen:

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

As a general rule of thumb, never use the == operator, except for convenience when comparing against null or undefined, where a == null will return true if a is null or undefined.

var a = null;
console.log(a == null); // true
console.log(a == undefined); // true

Strict equality operator (===)

The === operator, also known as the strict equality operator, checks for equality between two values without performing type coercion. This means that both the value and the type must be the same for the comparison to return true.

console.log(42 === '42'); // false
console.log(0 === false); // false
console.log(null === undefined); // false
console.log([] === false); // false
console.log('' === false); // false

For these comparisons, no type conversion is performed, so the statement returns false if the types are different. For instance, 42 === '42' is false because the types (number and string) are different.

// Comparison with type coercion (==)
console.log(42 == '42'); // true
console.log(0 == false); // true
console.log(null == undefined); // true

// Strict comparison without type coercion (===)
console.log(42 === '42'); // false
console.log(0 === false); // false
console.log(null === undefined); // false

Bonus: Object.is()

There's one final value-comparison operation within JavaScript, that is the Object.is() static method. The only difference between Object.is() and === is how they treat of 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

• Use == when you want to compare values with type coercion (and understand the implications of it). In practice, the only reasonable use case for the equality operator is to check for both null and undefined in a single comparison for convenience.
• Use === when you want to ensure both the value and the type are the same, which is the safer and more predictable choice in most cases.

Notes

• 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.
• ESLint's eqeqeq rule enforces the use of strict equality operators === and !== and even provides an option to always enforce strict equality except when comparing with the null literal.

Further reading

• Equality (==) | MDN
• Strict equality (===) | MDN

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), 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.

The unfortunate truth is that it is extremely hard to explain the event loop well using only text. We recommend checking out one of the following excellent videos explaining the event loop:

• JavaScript Visualized - Event Loop, Web APIs, (Micro)task Queue (2024): Lydia Hallie is a popular educator on JavaScript and this is the best recent video explaining the event loop. There's also an accompanying blog post for those who prefer detailed text-based explanations.
• In the Loop (2018): Jake Archibald previously from the Chrome team provides a visual demonstration of the event loop during JSConf 2018, accounting for different types of tasks.
• What the heck is the event loop anyway? (2014): Philip Robert's gave this epic talk at JSConf 2014 and it is one of the most viewed JavaScript videos on YouTube.

We recommend watching Lydia's video as it is the most modern and concise explanation standing at only 13 minutes long whereas the other videos are at least 30 minutes long. Her video is sufficient for the purpose of interviews.

Event loop in JavaScript

The event loop is the heart of JavaScript's asynchronous operation. It is a mechanism that handles the execution of code, allowing for asynchronous operations and ensuring that the single-threaded nature of JavaScript engines does not block the execution of the program.

Parts of the event loop

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

Call stack

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 task queue, also known as the macrotask queue / callback queue / event queue, is a queue that holds tasks that need to be executed. These tasks are typically asynchronous operations, such as callbacks passed to web APIs (setTimeout(), setInterval(), HTTP requests, etc.), and user interface event handlers like clicks, scrolls, etc.

Microtasks queue

Microtasks are tasks that have a higher priority than macrotasks and are executed immediately after the currently executing script is completed and before the next macrotask is executed. Microtasks are usually used for more immediate, lightweight operations that should be executed as soon as possible after the current operation completes. There is a dedicated microtask queue for microtasks. Microtasks include promises callbacks (then(), catch(), and finally()), await statements, queueMicrotask(), and MutationObserver callbacks.

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 following code logs some statements using a combination of normal execution, macrotasks, and microtasks.

console.log('Start');

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

Promise.resolve().then(() => {
  console.log('Promise 1');
});

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

console.log('End');

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

Explanation of the output:

1. Start and End are logged first because they are part of the initial script.
2. Promise 1 is logged next because promises are microtasks and microtasks are executed immediately after the items on the call stack.
3. Timeout 1 and Timeout 2 are logged last because they are macrotasks and are processed after the microtasks.

Further reading and resources

• The event loop - MDN
• The Node.js Event Loop
• Event loop: microtasks and macrotasks
• JavaScript Visualized: Event Loop by Lydia Hallie
• "JavaScript Visualized - Event Loop, Web APIs, (Micro)task Queue" by Lydia Hallie
• "What the heck is the event loop anyway?" by Philip Robert
• "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.

Pitfalls

Do note that event delegation come with certain pitfalls:

• Incorrect target handling: Ensure correct identification of the event target to avoid unintended actions.
• Not all events can be delegated/bubbled: Not all events can be delegated because they are not bubbled. Non-bubbling events include: focus, blur, scroll, mouseenter, mouseleave, resize, etc.
• Event overhead: While event delegation is generally more efficient, there needs to be complex logic written within the root event listener to identify the triggering element and respond appropriately. This can introduce overhead and can be potentially more complex if not managed properly.

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 it's 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.

Using 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, the this is lexically scoped, which means it inherits the this value from its surrounding scope at the time they are 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 introduces arrow functions which uses the enclosing lexical scope. This is usually convenient, but 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

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 needs 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 Storages have 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 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 have 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 have 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();

Notes

There are also other client-side storage mechanisms like IndexedDB which is more powerful than the above-mentioned technologies but more complicated to use.

References

• What is the difference between localStorage, sessionStorage, session and cookies?

TL;DR

All of these ways (<script>, <script async>, and <script defer>) are used to load and execute JavaScript files in an HTML document, but they differ in how the browser handles loading and execution of the script:

• <script> is the default way of including JavaScript. The browser blocks HTML parsing while the script is being downloaded and executed. The browser will not continue rendering the page until the script has finished executing.
• <script async> downloads the script asynchronously, in parallel with parsing the HTML. Executes the script as soon as it is available, potentially interrupting the HTML parsing. <script async> do not wait for each other and execute in no particular order.
• <script defer> downloads the script asynchronously, in parallel with parsing the HTML. However, the execution of the script is deferred until HTML parsing is complete, in the order they appear in the HTML.

Here's a table summarizing the 3 ways of loading <script>s in a HTML document.

What <script> tags are for

<script> tags are used to include JavaScript on a web page. The async and defer attributes are used to change how/when the loading and execution of the script happens.

<script>

For normal <script> tags without any async or defer, when they are encountered, HTML parsing is blocked, the script is fetched and executed immediately. HTML parsing resumes after the script is executed. This can block rendering of the page if the script is large.

Use <script> for critical scripts that the page relies on to render properly.

<!doctype html>
<html>
  <head>
    <title>Regular Script</title>
  </head>
  <body>
    <!-- Content before the script -->
    <h1>Regular Script Example</h1>
    <p>This content will be rendered before the script executes.</p>

    <!-- Regular script -->
    <script src="regular.js"></script>

    <!-- Content after the script -->
    <p>This content will be rendered after the script executes.</p>
  </body>
</html>

<script async>

In <script async>, the browser downloads the script file asynchronously (in parallel with HTML parsing) and executes it as soon as it is available (potentially before HTML parsing completes). The execution will not necessarily be executed in the order in which it appears in the HTML document. This can improve perceived performance because the browser doesn't wait for the script to download before continuing to render the page.

Use <script async> when the script is independent of any other scripts on the page, for example, analytics and ads scripts.

<!doctype html>
<html>
  <head>
    <title>Async Script</title>
  </head>
  <body>
    <!-- Content before the script -->
    <h1>Async Script Example</h1>
    <p>This content will be rendered before the async script executes.</p>

    <!-- Async script -->
    <script async src="async.js"></script>

    <!-- Content after the script -->
    <p>
      This content may be rendered before or after the async script executes.
    </p>
  </body>
</html>

<script defer>

Similar to <script async>, <script defer> also downloads the script in parallel to HTML parsing but the script is only executed when the document has been fully parsed and before firing DOMContentLoaded. If there are multiple of them, each deferred script is executed in the order they appeared in the HTML document.

If a script relies on a fully-parsed DOM, the defer attribute will be useful in ensuring that the HTML is fully parsed before executing.

<!doctype html>
<html>
  <head>
    <title>Deferred Script</title>
  </head>
  <body>
    <!-- Content before the script -->
    <h1>Deferred Script Example</h1>
    <p>This content will be rendered before the deferred script executes.</p>

    <!-- Deferred script -->
    <script defer src="deferred.js"></script>

    <!-- Content after the script -->
    <p>This content will be rendered before the deferred script executes.</p>
  </body>
</html>

Notes

• The async attribute should be used for scripts that are not critical to the initial rendering of the page and do not depend on each other, while the defer attribute should be used for scripts that depend on / is depended on by another script.
• The async and defer attributes are ignored for scripts that have no src attribute.
• <script>s with defer or async that contain document.write() will be ignored with a message like "A call to document.write() from an asynchronously-loaded external script was ignored".
• Even though async and defer help to make script downloading asynchronous, the scripts are still eventually executed on the main thread. If these scripts are computationally intensive, it can result in laggy/frozen UI. Partytown is a library that helps relocate script executions into a web worker and off the main thread, which is great for third-party scripts where you do not have control over the code.

Further reading

• <script>: The Script element | MDN
• async vs defer attributes

TL;DR

Undeclared

Undeclared variables are created when you assign a value to an identifier that is not previously created using var, let or const. Undeclared variables will be defined globally, outside of the current scope. In strict mode, a ReferenceError will be thrown when you try to assign to an undeclared variable. Undeclared variables are bad in the same way that global variables are bad. Avoid them at all cost! To check for them, wrap its usage in a try/catch block.

function foo() {
  x = 1; // Throws a ReferenceError in strict mode
}

foo();
console.log(x); // 1 (if not in strict mode)

Using the typeof operator on undeclared variables will give 'undefined'.

console.log(typeof y === 'undefined'); // true

undefined

A variable that is undefined is a variable that has been declared, but not assigned a value. It is of type undefined. If a function does not return a value, and its result is assigned to a variable, that variable will also have the value undefined. To check for it, compare using the strict equality (===) operator or typeof which will give the 'undefined' string. Note that you should not be using the loose equality operator (==) to check, as it will also return true if the value is null.

let foo;
console.log(foo); // undefined
console.log(foo === undefined); // true
console.log(typeof foo === 'undefined'); // true

console.log(foo == null); // true. Wrong, don't use this to check if a value is undefined!

function bar() {} // Returns undefined if there is nothing returned.
let baz = bar();
console.log(baz); // undefined

null

A variable that is null will have been explicitly assigned to the null value. It represents no value and is different from undefined in the sense that it has been explicitly assigned. To check for null, simply compare using the strict equality operator. Note that like the above, you should not be using the loose equality operator (==) to check, as it will also return true if the value is undefined.

const foo = null;
console.log(foo === null); // true
console.log(typeof foo === 'object'); // true

console.log(foo == undefined); // true. Wrong, don't use this to check if a value is null!

Notes

• As a good habit, never leave your variables undeclared or unassigned. Explicitly assign null to them after declaring if you don't intend to use them yet.
• Always explicitly declare variables before using them to prevent errors.
• Using some static analysis tooling in your workflow (e.g. ESLint, TypeScript Compiler), will enable checks that you are not referencing undeclared variables.

Practice

Practice implementing type utilities that check for null and undefined on GreatFrontEnd.

Further Reading

• MDN Web Docs: null
• MDN Web Docs: undefined
• MDN Web Docs: ReferenceError

TL;DR

.call and .apply are both used to invoke functions with a specific this context and arguments. The primary difference lies in how they accept arguments:

• .call(thisArg, arg1, arg2, ...): Takes arguments individually.
• .apply(thisArg, [argsArray]): Takes arguments as an array.

Assuming we have a function add, the function can be invoked using .call and .apply in the following manner:

function add(a, b) {
  return a + b;
}

console.log(add.call(null, 1, 2)); // 3
console.log(add.apply(null, [1, 2])); // 3

Call vs Apply

Both .call and .apply are used to invoke functions and the first parameter will be used as the value of this within the function. However, .call takes in comma-separated arguments as the next arguments while .apply takes in an array of arguments as the next argument.

An easy way to remember this is C for call and comma-separated and A for apply and an array of arguments.

function add(a, b) {
  return a + b;
}

console.log(add.call(null, 1, 2)); // 3
console.log(add.apply(null, [1, 2])); // 3

With ES6 syntax, we can invoke call using an array along with the spread operator for the arguments.

function add(a, b) {
  return a + b;
}

console.log(add.call(null, ...[1, 2])); // 3

Use cases

Context management

.call and .apply can set the this context explicitly when invoking methods on different objects.

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

const anotherPerson = { name: 'Alice' };

person.greet.call(anotherPerson); // Hello, my name is Alice
person.greet.apply(anotherPerson); // Hello, my name is Alice

Function borrowing

Both .call and .apply allow borrowing methods from one object and using them in the context of another. This is useful when passing functions as arguments (callbacks) and the original this context is lost. .call and .apply allow the function to be invoked with the intended this value.

function greet() {
  console.log(`Hello, my name is ${this.name}`);
}

const person1 = { name: 'John' };
const person2 = { name: 'Alice' };

greet.call(person1); // Hello, my name is John
greet.apply(person2); // Hello, my name is Alice

Alternative syntax to call methods on objects

.apply can be used with object methods by passing the object as the first argument followed by the usual parameters.

const arr1 = [1, 2, 3];
const arr2 = [4, 5, 6];

Array.prototype.push.apply(arr1, arr2); // Same as arr1.push(4, 5, 6)

console.log(arr1); // [1, 2, 3, 4, 5, 6]

Deconstructing the above:

1. The first object, arr1 will be used as the this value.
2. .push() is called on arr1 using arr2 as arguments as an array because it's using .apply().
3. Array.prototype.push.apply(arr1, arr2) is equivalent to arr1.push(...arr2).

It may not be obvious, but Array.prototype.push.apply(arr1, arr2) causes modifications to arr1. It's clearer to call methods using the OOP-centric way instead where possible.

Follow-Up Questions

• How do .call and .apply differ from Function.prototype.bind?

Practice

Practice implementing your own Function.prototype.call method and Function.prototype.apply method on GreatFrontEnd.

Further Reading

• Function.prototype.call | MDN
• Function.prototype.apply | MDN

TL;DR

Function.prototype.bind is a method in JavaScript that allows you to create a new function with a specific this value and optional initial arguments. It's primary purpose is to:

• Binding this value to preserve context: The primary purpose of bind is to bind the this value of a function to a specific object. When you call func.bind(thisArg), it creates a new function with the same body as func, but with this permanently bound to thisArg.
• Partial application of arguments: bind also allows you to pre-specify arguments for the new function. Any arguments passed to bind after thisArg will be prepended to the arguments list when the new function is called.
• Method borrowing: bind allows you to borrow methods from one object and apply them to another object, even if they were not originally designed to work with that object.

The bind method is particularly useful in scenarios where you need to ensure that a function is called with a specific this context, such as in event handlers, callbacks, or method borrowing.

Function.prototype.bind

Function.prototype.bind allows you to create a new function with a specific this context and, optionally, preset arguments. bind() is most useful for preserving the value of this in methods of classes that you want to pass into other functions.

bind was frequently used on legacy React class component methods which were not defined using arrow functions.

const john = {
  age: 42,
  getAge: function () {
    return this.age;
  },
};

console.log(john.getAge()); // 42

const unboundGetAge = john.getAge;
console.log(unboundGetAge()); // undefined

const boundGetAge = john.getAge.bind(john);
console.log(boundGetAge()); // 42

const mary = { age: 21 };
const boundGetAgeMary = john.getAge.bind(mary);
console.log(boundGetAgeMary()); // 21

In the example above, when the getAge method is called without a calling object (as unboundGetAge), the value is undefined because the value of this within getAge() becomes the global object. boundGetAge() has its this bound to john, hence it is able to obtain the age of john.

We can even use getAge on another object which is not john! boundGetAgeMary returns the age of mary.

Use cases

Here are some common scenarios where bind is frequently used:

Preserving context and fixing the this value in callbacks

When you pass a function as a callback, the this value inside the function can be unpredictable because it is determined by the execution context. Using bind() helps ensure that the correct this value is maintained.

class Person {
  constructor(firstName) {
    this.firstName = firstName;
  }
  greet() {
    console.log(`Hello, my name is ${this.firstName}`);
  }
}

const john = new Person('John');

// Without bind(), `this` inside the callback will be the global object
setTimeout(john.greet, 1000); // Output: "Hello, my name is undefined"

// Using bind() to fix the `this` value
setTimeout(john.greet.bind(john), 2000); // Output: "Hello, my name is John"

You can also use arrow functions to define class methods for this purpose instead of using bind. Arrow functions have the this value bound to its lexical context.

class Person {
  constructor(name) {
    this.name = name;
  }
  greet = () => {
    console.log(`Hello, my name is ${this.name}`);
  };
}

const john = new Person('John Doe');
setTimeout(john.greet, 1000); // Output: "Hello, my name is John Doe"

Partial application of functions (currying)

bind can be used to create a new function with some arguments pre-set. This is known as partial application or currying.

function multiply(a, b) {
  return a * b;
}

// Using bind() to create a new function with some arguments pre-set
const multiplyBy5 = multiply.bind(null, 5);
console.log(multiplyBy5(3)); // Output: 15

Method borrowing

bind allows you to borrow methods from one object and apply them to another object, even if they were not originally designed to work with that object. This can be handy when you need to reuse functionality across different objects

const person = {
  name: 'John',
  greet: function () {
    console.log(`Hello, ${this.name}!`);
  },
};

const greetPerson = person.greet.bind({ name: 'Alice' });
greetPerson(); // Output: Hello, Alice!

Practice

Try implementing your own Function.prototype.bind() method on GreatFrontEnd.

Further Reading

• Function.prototype.bind() - JavaScript | MDN
• Function Binding | javascript.info

TL;DR

The main advantage of using an arrow function as a method inside a constructor is that the value of this gets set at the time of the function creation and can't change after that. When the constructor is used to create a new object, this will always refer to that object.

For example, let's say we have a Person constructor that takes a first name as an argument has two methods to console.log() that name, one as a regular function and one as an arrow function:

const Person = function (name) {
  this.firstName = name;
  this.sayName1 = function () {
    console.log(this.firstName);
  };
  this.sayName2 = () => {
    console.log(this.firstName);
  };
};

const john = new Person('John');
const dave = new Person('Dave');

john.sayName1(); // John
john.sayName2(); // John

// The regular function can have its `this` value changed, but the arrow function cannot
john.sayName1.call(dave); // Dave (because `this` is now the dave object)
john.sayName2.call(dave); // John

john.sayName1.apply(dave); // Dave (because `this` is now the dave object)
john.sayName2.apply(dave); // John

john.sayName1.bind(dave)(); // Dave (because `this` is now the dave object)
john.sayName2.bind(dave)(); // John

const sayNameFromWindow1 = john.sayName1;
sayNameFromWindow1(); // undefined (because `this` is now the window object)

const sayNameFromWindow2 = john.sayName2;
sayNameFromWindow2(); // John

The main takeaway here is that this can be changed for a normal function, but this always stays the same for an arrow function. So even if you are passing around your arrow function to different parts of your application, you wouldn't have to worry about the value of this changing.

Arrow functions

Arrow functions are introduced in ES2015 and it provides a concise way to write functions in Javascript. One of the key features of arrow function is that it lexically bind the this value, which means that it takes the this value from enclosing scope.

Syntax

Arrow functions use the => syntax instead of the function keyword. The basic syntax is:

const myFunction = (arg1, arg2, ...argN) => {
  // function body
};

If the function body has only one expression, you can omit the curly braces and the return keyword:

const myFunction = (arg1, arg2, ...argN) => expression;

Examples

// Arrow function with parameters
const multiply = (x, y) => x * y;
console.log(multiply(2, 3)); // Output: 6

// Arrow function with no parameters
const sayHello = () => 'Hello, World!';
console.log(sayHello()); // Output: 'Hello, World!'

Advantages

• Concise: Arrow functions provide a more concise syntax, especially for short functions.
• Implicit return: They have an implicit return for single-line functions.
• Value of this is predictable: Arrow functions lexically bind the this value, inheriting it from the enclosing scope.

Limitations

Arrow functions cannot be used as constructors and will throw an error when used with the new keyword.

const Foo = () => {};
const foo = new Foo(); // TypeError: Foo is not a constructor

They also do not have arguments keyword; the arguments have to be obtained from using the rest operator (...) in the arguments.

const arrowFunction = (...args) => {
  console.log(arguments); // Throws a ReferenceError
  console.log(args); // [1, 2, 3]
};

arrowFunction(1, 2, 3);

Since arrow functions do not have their own this, they are not suitable for defining methods in an object. Traditional function expressions or function declarations should be used instead.

const obj = {
  value: 42,
  getValue: () => this.value, // `this` does not refer to `obj`
};

console.log(obj.getValue()); // undefined

Why arrow functions are useful

One of the most notable features of arrow functions is their behavior with this. Unlike regular functions, arrow functions do not have their own this. Instead, they inherit this from the parent scope at the time they are defined. This makes arrow functions particularly useful for scenarios like event handlers, callbacks, and methods in classes.

Arrow functions inside function constructors

const Person = function (name) {
  this.firstName = name;
  this.sayName1 = function () {
    console.log(this.firstName);
  };
  this.sayName2 = () => {
    console.log(this.firstName);
  };
};

const john = new Person('John');
const dave = new Person('Dave');

john.sayName1(); // John
john.sayName2(); // John

// The regular function can have its `this` value changed, but the arrow function cannot
john.sayName1.call(dave); // Dave (because `this` is now the dave object)
john.sayName2.call(dave); // John

john.sayName1.apply(dave); // Dave (because `this` is now the dave object)
john.sayName2.apply(dave); // John

john.sayName1.bind(dave)(); // Dave (because `this` is now the dave object)
john.sayName2.bind(dave)(); // John

const sayNameFromWindow1 = john.sayName1;
sayNameFromWindow1(); // undefined (because `this` is now the window object)

const sayNameFromWindow2 = john.sayName2;
sayNameFromWindow2(); // John

Arrow functions in event handlers

const button = document.getElementById('myButton');

button.addEventListener('click', function () {
  console.log(this); // Output: Button
  console.log(this === button); // Output: true
});

button.addEventListener('click', () => {
  console.log(this); // Output: Window
  console.log(this === window); // Output: true
});

This can be particularly helpful in React class components. If you define a class method for something such as a click handler using a normal function, and then you pass that click handler down into a child component as a prop, you will need to also bind this in the constructor of the parent component. If you instead use an arrow function, there is no need to bind this, as the method will automatically get its this value from its enclosing lexical context. See this article for an excellent demonstration and sample code.

Further reading

• Arrow function expressions - MDN
• How to Use JavaScript Arrow Functions – Explained in Detail

TL;DR

Prototypical inheritance in JavaScript is a way for objects to inherit properties and methods from other objects. Every JavaScript object has a special hidden property called [[Prototype]] (commonly accessed via __proto__ or using Object.getPrototypeOf()) that is a reference to another object, which is called the object's "prototype".

When a property is accessed on an object and if the property is not found on that object, the JavaScript engine looks at the object's __proto__, and the __proto__'s __proto__ and so on, until it finds the property defined on one of the __proto__s or until it reaches the end of the prototype chain.

This behavior simulates classical inheritance, but it is really more of delegation than inheritance.

Here's an example of prototypal inheritance:

// Parent object constructor.
function Animal(name) {
  this.name = name;
}

// Add a method to the parent object's prototype.
Animal.prototype.makeSound = function () {
  console.log('The ' + this.constructor.name + ' makes a sound.');
};

// Child object constructor.
function Dog(name) {
  Animal.call(this, name); // Call the parent constructor.
}

// Set the child object's prototype to be the parent's prototype.
Object.setPrototypeOf(Dog.prototype, Animal.prototype);

// Add a method to the child object's prototype.
Dog.prototype.bark = function () {
  console.log('Woof!');
};

// Create a new instance of Dog.
const bolt = new Dog('Bolt');

// Call methods on the child object.
console.log(bolt.name); // "Bolt"
bolt.makeSound(); // "The Dog makes a sound."
bolt.bark(); // "Woof!"