Can we bind this in an arrow function? What happens if we use the new operator with an arrow function
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.
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 })(); // ignoredcall, 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 constructorArrow 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 forthis.new ArrowFn()→ TypeError, they're not constructors (no[[Construct]], noprototype).- 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.