Arrow Functions vs Regular Functions

An arrow function is a shorter syntax with a smaller feature set. It has no own this binding, no own arguments object, no prototype property and it cannot be called with the new keyword. Use one when you are writing a short callback that does not need a dynamic this, and avoid it when you need an object method, a constructor or a prototype method.

// Arrow: expression body, no own this, no own arguments.
const double = (n) => n * 2;
const doubleLong = (n) => {
  return n * 2;
};

console.log(double(4));      // 8
console.log(doubleLong(4));  // 8

// A regular function can be used as a constructor.
function Point(x, y) {
  this.x = x;
  this.y = y;
}
const point = new Point(1, 2);
console.log(point.x, point.y);   // 1 2

try {
  new (() => {})();
} catch (err) {
  console.log("new arrow:", err.name);   // "TypeError"
}

The other difference that catches people is that an arrow function has no prototype property, so the new keyword has nothing to build an instance from and throws a TypeError. That is the same rule that stops you using an arrow function as a class constructor or as an event handler that relies on the element being the receiver.

Arrow functions also have no arguments object. Inside an arrow, the word arguments refers to the enclosing function's arguments object, or fails in a module top-level context. If you need the arguments, use a rest parameter.

There is a readability point as well. The single-expression form is shorter, but for anything longer than a couple of lines a regular function with a block body is clearer, and some style guides require braces and an explicit return so that a missing return cannot slip through.

Because an arrow function has no this binding of its own to define. When the language evaluates the body of an arrow function, the word this is resolved from the scope the arrow was written in, and it keeps pointing at the same thing no matter how the arrow is later called.

This was a deliberate design decision rather than an oversight. Before arrow functions existed, the behaviour of this in a callback depended entirely on how the callback was invoked. Passing a method to something like setTimeout or an event listener lost the receiver, because the callback was called with no receiver at all. Every codebase had workarounds: saving a reference to this in a variable at the top of the function, or binding the function in the constructor.

Arrow functions remove the need for those workarounds in the places where the surrounding scope already has the right value. Inside a class method, the arrow sees the instance. Inside a constructor, it sees the object being built. Inside a callback passed to a timer created in that same method, it still sees the instance.

There is a useful way to phrase it for an interviewer. A regular function's this is determined by the call site, which means the function's behaviour depends on how it is called. An arrow function's this is determined by where it was written. That is the whole difference, and it explains both when arrows are the right tool and when they silently capture the wrong value.

A regular function gets its this from the call site, so detaching it from the object loses the receiver. An arrow function keeps the this of the scope it was written in, so it is unaffected by how it is called.

const label = "Save";

const handlers = {
  regular: function () { return this === globalThis; },
  arrow: () => label,
};

const regular = handlers.regular;
const arrow = handlers.arrow;

console.log("detached regular function:", regular());   // true - this became the global object
console.log("detached arrow function:", arrow());        // "Save" - lexical this

// The usual workaround: use a method shorthand, which keeps a dynamic this.
class Service {
  constructor(items) { this.items = items; }
  total() {
    // The arrow inside the method inherits the method's this.
    return this.items.reduce((sum, n) => sum + n, 0);
  }
}

console.log(new Service([1, 2, 3]).total());   // 6

Two practical rules come out of this. If you need the object as the receiver, use the method shorthand syntax, because a method always gets a dynamic this and therefore works when it is passed around. If you want to keep a reference to the object inside a callback, use an arrow function, because it captures the surrounding this at the moment it is created.

The classic bug is the reverse: using an arrow function as a class method or as an object method and then being surprised that this is not the object. The symptom is usually an error about reading a property of the global object, or a value that mysteriously comes from the outer scope.

There is a third option worth knowing for library code: the bind method. Calling a function with a fixed receiver produces a new function that always uses that receiver, which is how you keep a regular function's dynamic this but pin it down.