In a regular function, the this keyword is dynamic. Its value depends on how the function is called (e.g., as a method of an object, as a constructor, etc.).
In an arrow function, this is lexical. It does not have its own this. Instead, it inherits this from the surrounding parent scope (the execution context where it was defined).
Regular Functions can be used as constructors to create new objects using the new keyword.
Arrow Functions cannot be used as constructors. They lack the internal [[Construct]] method and don't have a prototype property.
Regular Functions have access to an arguments object, which is an array-like object containing all values passed to the function.
Arrow Functions do not have their own arguments object. If you try to use it, they will look to the parent scope. (Modern tip: Use Rest Parameters (...args) => {} instead).
Implicit Return If an arrow function has only one expression, you can omit the curly braces and the return keyword.
Parameter Parentheses: If there is exactly one parameter, you can omit the parentheses.
You need to write a small utility that maps over an array and returns a new array of doubled numbers. Would you use an arrow function or a regular function for the callback, and why?
If you write const obj = { value: 10, get: function() { return this.value; } }; and then change get to an arrow function, what will obj.get() return and why?
While refactoring a component, a teammate replaced a method defined with function with an arrow function, and now this.setState is undefined. Walk me through why that happened and how you'd fix it.
Our codebase has a mix of arrow functions and regular functions for event handlers. How would you decide which to use when handling DOM events that need to be removed later?
We are building a library that needs to support both older browsers and modern environments. Discuss the trade‑offs of using arrow functions throughout the codebase versus regular functions, considering transpilation, performance, and readability.
A performance‑critical loop creates thousands of functions each iteration. How does the choice between arrow functions and regular functions affect memory usage and garbage collection, and what would you recommend?
Our organization is planning a migration to a new coding standard that enforces consistent this handling. How would you design a linting rule or code‑review guideline around arrow vs regular functions to avoid bugs across multiple teams?
When designing a shared utility module that will be consumed by many services, what considerations would you make about exposing functions as arrow functions versus regular functions, especially regarding testability and binding behavior?