If you’ve ever debugged a JavaScript application and found yourself wondering why this suddenly refers to the window object instead of your carefully crafted object, you’re not alone. The this keyword in JavaScript is perhaps the language’s most confusing feature—so confusing that an entire cottage industry of blog posts, Stack Overflow questions, and conference talks exists just to explain it.
The irony? This confusion wasn’t inevitable. It’s the result of early design decisions that made sense in 1995 but haunt developers to this day. Let’s explore why JavaScript’s this binding became one of the language’s biggest design regrets and what it teaches us about evolving languages while maintaining backward compatibility.
1. The Root of Confusion: Dynamic vs Lexical Binding
Most programming languages determine variable scope using lexical scoping—where a variable refers to is determined by where it’s written in the code. Look at the code, trace the scope chain, and you know what a variable means. Simple, predictable, readable.
JavaScript uses lexical scoping for almost everything. Variables declared with let, const, and even var follow lexical rules. You can look at the code and know exactly what scope a variable belongs to.
Except for this.
The Core Problem: JavaScript’s
thisuses dynamic binding—its value is determined by how a function is called, not where it’s defined. The same function can have differentthisvalues depending on the calling context.
This fundamental mismatch creates cognitive dissonance. Developers learn to think lexically for 99% of JavaScript, then must switch to dynamic thinking for this. It’s like driving on the right side of the road, except on Tuesdays when you drive on the left.
2. The Four Binding Rules (And Why You Need to Memorize Them)
Understanding this requires memorizing four different binding rules and their precedence. The fact that this list exists is itself evidence of poor design—good language features shouldn’t require rulebooks.
1. Default Binding (The “Oops” Binding)
When a function is called without any context, this defaults to the global object (window in browsers, global in Node.js). In strict mode, it’s undefined instead.
function greeting() { console.log(this.name); } var name = "Global Name"; greeting(); // "Global Name" (or undefined in strict mode)
This is the binding that catches beginners off guard. They expect this to refer to something meaningful, but it refers to the global scope—which is almost never what you want.
2. Implicit Binding (The “Dot Rule”)
When a function is called as a method of an object, this refers to that object. This feels intuitive because it mirrors how methods work in class-based languages.
const person = { name: "Alice", greet: function() { console.log(this.name); } }; person.greet(); // "Alice"
This works as expected—until you extract the method from the object.
const greetingFunc = person.greet; greetingFunc(); // undefined (or error in strict mode)
The function is the same, but because it’s no longer called with the dot notation, this loses its binding. This is where the confusion really begins.
3. Explicit Binding (The “You’re in Control” Binding)
JavaScript provides call, apply, and bind methods to explicitly set this. These exist precisely because implicit binding is unreliable.
function greet() { console.log(this.name); } const person1 = { name: "Bob" }; const person2 = { name: "Charlie" }; greet.call(person1); // "Bob" greet.call(person2); // "Charlie"
The bind method creates a new function with this permanently bound to a specific value. Before arrow functions, bind was the primary way to preserve this in callbacks.
4. New Binding (The Constructor Rule)
When a function is called with the new keyword, JavaScript creates a new object and sets this to refer to that object.
function Person(name) { this.name = name; } const alice = new Person("Alice"); console.log(alice.name); // "Alice"
This mimics class-based object-oriented languages, but it’s actually just another binding rule layered onto JavaScript’s prototype system.
Precedence: When Rules Collide
What happens when multiple rules could apply? JavaScript has a precedence order: new binding beats explicit binding, which beats implicit binding, which beats default binding. Memorizing this hierarchy is part of the JavaScript developer’s rite of passage.
| Binding Type | Trigger | Common Pitfalls | Precedence |
|---|---|---|---|
| Default | Standalone function call | Unexpected global object reference | Lowest (4th) |
| Implicit | Method call (object.method()) | Lost binding when passing as callback | Low (3rd) |
| Explicit | call(), apply(), bind() | Verbose, must remember to use | High (2nd) |
| New | new keyword with function | Confusion with regular function calls | Highest (1st) |
What happens when multiple rules could apply? JavaScript has a precedence order that developers must memorize to predict behavior accurately.
3. The Callback Catastrophe
Nowhere is the this problem more apparent than with callbacks. Event handlers, array methods, and asynchronous operations all lose their this binding in ways that violate developer expectations.
class Button { constructor(label) { this.label = label; } click() { console.log(`${this.label} clicked`); } } const btn = new Button("Submit"); document.querySelector("button").addEventListener("click", btn.click); // Error: Cannot read property 'label' of undefined
The click method works fine when called as btn.click(), but passing it as a callback strips away the this binding. Developers had to work around this with patterns that now look archaic:
// The old-school workaround const self = this; document.querySelector("button").addEventListener("click", function() { self.click(); });
The self = this pattern became so common that it was practically a JavaScript idiom. The fact that thousands of developers independently arrived at this workaround reveals the depth of the design problem.
4. Arrow Functions: The Band-Aid That Stuck
ES6 introduced arrow functions in 2015, and they fundamentally changed how developers handle this. Arrow functions don’t have their own this binding—they inherit it lexically from their enclosing scope.
class Button { constructor(label) { this.label = label; } // Arrow function captures 'this' lexically click = () => { console.log(`${this.label} clicked`); } } const btn = new Button("Submit"); document.querySelector("button").addEventListener("click", btn.click); // Works perfectly!
Arrow functions solve the callback problem elegantly. They behave the way most developers initially expect regular functions to behave. The this value is determined by where the function is written, not how it’s called.
Why Arrow Functions Are a Band-Aid, Not a Cure
Arrow functions didn’t fix JavaScript’s this problem—they introduced a second, incompatible system. Now JavaScript has two function types with fundamentally different this behavior:
| Feature | Regular Functions | Arrow Functions |
|---|---|---|
| this Binding | Dynamic (call-site dependent) | Lexical (inherited from parent) |
| Can Use as Constructor | Yes (with new keyword) | No (throws error) |
| Has arguments Object | Yes | No (inherits from parent) |
| Can Change this with bind() | Yes | No (this is fixed) |
| Use as Method | Recommended | Problematic (loses dynamic binding) |
Developers now must choose the right function type for their use case. Arrow functions for callbacks and closures, regular functions for methods and constructors. It’s better than the pre-ES6 chaos, but it’s still a patch over a fundamental design issue.
The data shows how dramatically arrow functions have replaced older workarounds:
5. What Other Languages Got Right
Looking at how other languages handle similar problems reveals that JavaScript’s approach was never inevitable.
Python’s Explicit Self
Python requires methods to explicitly accept self as their first parameter. There’s no magic this binding—the object reference is passed like any other argument. This removes all ambiguity.
# Python approach class Person: def greet(self): print(self.name)
When you call person.greet(), Python automatically passes person as the first argument. But there’s no mystery—the mechanism is visible and predictable.
Rust’s Ownership System
Rust takes an entirely different approach with method syntax that makes ownership explicit. Methods must explicitly declare whether they’re borrowing or consuming the object.
Modern JavaScript Classes
Interestingly, JavaScript’s own class syntax (introduced in ES6) behaves more predictably than traditional function-based approaches. Combined with arrow function properties, classes provide a more intuitive mental model—though they’re ultimately just syntactic sugar over the same problematic mechanisms.
6. The Backward Compatibility Prison
Why doesn’t JavaScript just fix this? The answer lies in one of the web’s core principles: don’t break the web.
JavaScript code from 1995 still runs in modern browsers. Millions of websites depend on JavaScript’s current behavior, quirks and all. Changing how this works would break countless existing applications—a price the web platform cannot afford to pay.
The Compatibility Trap: Every language feature that seems like a mistake becomes permanent. Breaking changes might improve the language, but they also break the trust of developers and users who depend on stable behavior.
This is why TC39 (the committee that standardizes JavaScript) can only add features, never remove them. The language grows more complex over time as new features layer on top of old ones rather than replace them.
The Cost of Compatibility
Other languages have handled this differently. Python 3 introduced breaking changes from Python 2, accepting a painful multi-year transition period. The result was a cleaner language, but the community fragmentation lasted nearly a decade.
JavaScript chose the opposite path: absolute backward compatibility at the cost of accumulated complexity. Every new JavaScript developer must learn both the old ways and the new ways because both exist in production codebases.
The growth in language complexity illustrates this challenge:
7. Lessons in Language Design
Consistency Trumps Cleverness
JavaScript’s this binding tries to be clever by adapting to different contexts. But this cleverness creates complexity. A simpler, more consistent approach would have been easier to learn and less error-prone, even if it required more typing.
Explicit Is Better Than Implicit
The dynamic binding of this is entirely implicit—there’s nothing in the code that tells you what this will be. Python’s explicit self parameter makes the mechanism visible, removing mystery at the cost of a few extra characters.
Design for the Common Case
JavaScript’s this was designed for method calls and constructor functions. But the common case evolved to include callbacks, event handlers, and functional programming patterns. The design didn’t anticipate how the language would actually be used.
Evolution Must Be Incremental
Arrow functions demonstrate that languages can evolve even with strict backward compatibility requirements. The solution isn’t to fix the old feature—it’s to add a better alternative and let natural selection take its course as developers prefer the better approach.
8. Where We Are Today
Modern JavaScript has reached an uneasy equilibrium. Most developers follow these guidelines:
Use arrow functions for: callbacks, event handlers, array methods, any situation where you want lexical this binding.
Use regular functions for: object methods (when you need dynamic this), constructors (before class syntax), any function that will be called with new.
Use class syntax for: complex objects that need multiple methods and inheritance, combining regular methods with arrow function properties as needed.
Tools like ESLint and TypeScript help catch this-related bugs before they reach production. TypeScript’s type system can even detect when this is used incorrectly, providing compile-time safety for a runtime problem.
9. What We’ve Learned
JavaScript’s this keyword stands as a cautionary tale in language design—a feature that seemed sensible in isolation but created endless confusion in practice.
Dynamic binding creates cognitive overhead. While JavaScript uses lexical scoping for almost everything, this is dynamically bound based on how functions are called. This inconsistency forces developers to maintain two different mental models simultaneously.
Four binding rules govern this behavior. Default binding (global or undefined), implicit binding (object method calls), explicit binding (call/apply/bind), and new binding (constructor calls) each follow different rules with a specific precedence order. The complexity of these rules suggests a design problem.
Callbacks expose the worst of the problem. When functions are passed as callbacks for events, array methods, or asynchronous operations, they lose their this binding in counterintuitive ways. This led to workarounds like the self = this pattern.
Arrow functions are a band-aid, not a cure. ES6 arrow functions introduced lexical this binding, solving callback problems elegantly. However, they didn’t fix the underlying issue—they added a second function type with different semantics, increasing language complexity.
Other languages chose simpler approaches. Python’s explicit self parameter removes all ambiguity. The lesson: explicit mechanisms are easier to understand than implicit magic, even if they require more typing.
Backward compatibility prevents fixes. JavaScript cannot change this behavior without breaking millions of existing websites. The web’s “don’t break the web” principle means mistakes become permanent features. Languages can only evolve by adding better alternatives alongside problematic originals.
Language design requires predicting usage patterns. JavaScript’s this was optimized for method calls and constructors, but JavaScript evolved into a functional, callback-heavy language. Good design must anticipate how features will be used in practice, not just in theory.
Modern JavaScript provides better paths forward. Class syntax, arrow functions, and TypeScript’s type checking offer ways to avoid this pitfalls. The language improved not by fixing old mistakes but by providing better alternatives.
The this controversy teaches us that language design is about trade-offs, not perfection. Early decisions cast long shadows, and backward compatibility can turn short-term pragmatism into long-term technical debt. Yet JavaScript thrives despite these issues, proving that developer ecosystems and practical utility often matter more than theoretical elegance.
