Can you bind this in an arrow function, and what happens if you use the new operator with one?

No — arrow functions have no own 'this'; they capture it lexically from the enclosing scope, and call/apply/bind cannot override it. They also have no [[Construct]] internal method, so using 'new' with an arrow function throws a TypeError.

5 min read·~6 min to think through

Arrow functions deliberately don't have their own this — and that has two direct consequences for this question.

Can you bind `this` in an arrow function?

No. An arrow function has no own this binding. It captures this lexically — from the scope where it was defined — permanently.

const obj = {
  name: "obj",
  regular() { return this.name; },
  arrow: () => this.name,        // 'this' is from the enclosing scope, not obj
};
obj.regular();  // "obj"
obj.arrow();    // undefined (or window.name) — 'this' is NOT obj

const fn = () => this;
fn.call({ a: 1 });   // call's argument is IGNORED
fn.apply({ a: 1 });  // ignored
fn.bind({ a: 1 })(); // ignored

call, apply, and bind cannot change an arrow function's this — they silently have no effect on it. The this is fixed at definition time.

This is actually the useful property: arrow functions are perfect for callbacks (setTimeout, array methods, event handlers in class fields) precisely because they keep the surrounding this without needing .bind(this).

What happens with `new` on an arrow function?

It throws a TypeError.

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

Arrow functions are not constructors — they lack the internal [[Construct]] method that new requires. They also have no prototype property and no own arguments object. Since new needs to create an object, set its prototype, and bind this to it — none of which an arrow function supports — the engine rejects it outright.

Why arrow functions are designed this way

Regular functions get this from how they're called (dynamic). That flexibility caused endless bugs (this lost in callbacks). Arrow functions traded that flexibility away on purpose: this is lexical, fixed, and predictable — so they can't be re-bound and can't be constructors, because both of those depend on a dynamic this.

Quick summary

Arrow functions: no own this → lexical, captured at definition.
call/apply/bind → ignored for this.
new ArrowFn() → TypeError, they're not constructors (no [[Construct]], no prototype).
Also: no own arguments, can't be generators.

Follow-up questions

•Why is lexical this useful for callbacks?
•What other things do arrow functions lack besides their own this?
•How does a regular function get its this value?
•When should you NOT use an arrow function?

Common mistakes

•Expecting call/apply/bind to change an arrow function's this.
•Using an arrow function as a method and being surprised this isn't the object.
•Trying to use an arrow function as a constructor.
•Using an arrow function where you need a dynamic this (e.g. object methods, prototypes).

Performance considerations

Edge cases

•Arrow function as a class field — captures the instance's this, a common (intentional) pattern.
•Arrow function at module top level — this is undefined (modules) or the global object.
•Nested arrow functions all sharing the same lexical this.

Real-world examples

•Arrow callbacks in setTimeout / array methods / event handlers to preserve the surrounding this without .bind.
•The TypeError from `new (() => {})` shown to explain arrows aren't constructors.

Senior engineer discussion

Seniors explain that arrow functions have no own this (lexical capture), so call/apply/bind are no-ops for this, and that new throws because arrows lack [[Construct]] and prototype. The depth signal is framing it as a deliberate design tradeoff — arrows gave up dynamic this for predictability, which is exactly why they can't be re-bound or constructed.

Can you bind this in an arrow function?

What happens with new on an arrow function?