The this keyword

The call site, not the definition site. The same function can see a different this depending on how it is invoked — as a method, as a bare call, or bound in advance. That single rule explains nearly every this surprise: when context is lost, something changed how the function was called, usually by passing it as a callback.

New binding: new points this at the fresh object. Explicit: call, apply or bind set it directly. Implicit: calling as user.save() sets it to user. Default: a bare call gets undefined in strict mode (the global object in sloppy mode). When rules collide, new beats explicit beats implicit beats default — memorize that order and most puzzles solve themselves.

Because passing user.save as a callback separates the function from its object — setTimeout later invokes it as a bare function, so the implicit rule no longer applies and strict mode gives undefined. Fixes: wrap it (() => user.save()), which preserves the method-call form, or bind it once (user.save.bind(user)). Losing the dot is losing the receiver.

They don't have one. An arrow inherits this from the surrounding scope where it is written, permanently — call and bind cannot change it. That makes arrows ideal for callbacks inside methods (the handler keeps the component) and wrong for object methods or prototype functions that need a dynamic receiver. If this must vary per call, write function.

bind returns a NEW function with this (and optionally leading arguments) locked in; the original is untouched and nothing runs yet. Reach for it when handing a method to someone else: event listeners, timers, array callbacks, promises. One bind at handoff beats debugging a mystery undefined three stack frames later.

In class methods this is the instance — until the method is detached. A button.onclick = panel.save or setTimeout(panel.save) call loses the receiver exactly like plain objects do. The standard fixes are binding in the constructor, binding at handoff, or defining the handler as an arrow field (which closes over the instance). Frameworks hit this constantly, which is why the pattern is worth naming.

A bare call like save() gets undefined in strict mode and the global object (window/globalThis) otherwise. Strict mode's undefined fails fast and loud; sloppy mode silently reads and writes globals, hiding bugs. Modules are always strict, so modern code sees undefined — treat a surprise undefined this as a detached-method bug until proven otherwise.

new Cart() creates a fresh empty object, links it to Cart.prototype, runs the constructor with this pointing at that object, and returns it (unless the constructor returns its own object). Forgetting new runs the same function as a bare call — this is undefined in strict mode and the constructor's assignments throw instead of building anything.

Because the browser invokes the listener as a method of the element — the implicit rule again, with the element as receiver. Add the same listener via an arrow wrapper and this becomes whatever surrounded the arrow, which is why handler code mixing styles confuses readers. Modern handlers usually ignore this entirely and use the event object (event.target) instead — say so if the interviewer probes.

Look at the call, not the function: obj.fn() means obj, bare fn() means undefined (strict), fn.call(x) means x, new Fn() means the new object, and arrows mean "whatever surrounded me". Say that sentence in the interview, then apply it line by line — it resolves nearly every textbook puzzle out loud.