I think the main reason "this" is considered confusing is that many programmers learning JS have already spent years coding in Java or C#. They expect it to work the same, then get frustrated when it doesn't. But the reason it doesn't is due to the fact that functions in JS are first-class, and don't intrinsically belong to a particular class and object instance they way they do in those languages. As such, the context represented by "this" <i>has</i> to be more fluid in JS.<p>That's not to say that the design of "this" is perfect. And it doesn't help that JS' syntax was designed to resemble C-family languages that it differs from significantly. But nor it is some entirely arbitrary and illogical flaw. If you take the time, it's possible to gain an intuitive grasp of how functions and "this" work in JS. But instead, learners are too often told that "JS is quirky" by others who also have come to it from Java / C#, and never move past memorizing to a list of these "quirks" to genuine proficiency. They then grumble whenever they need to work on a JS codebase, because their incomplete understanding makes it feel like they're standing on quicksand.<p>Soon such devs fall into a circular trap: They don't like coding in JS because it feels weird and unintuitive. And they don't take the time to learn about it more deeply because they don't like coding with it, and don't want to waste time learning about something they dislike. But since they <i>have</i> to code with it, because it's part of their job, they just stumble along, hacking away and getting frustrated when things don't work, then come onto Hacker News and blow off steam about what a garbage language JS is.
This would have been a good post in 2014 but it shouldn't be relevant to any JavaScript developers in 2018.<p>Arrow functions don't have `this`, and `...` syntax is simpler and as efficient as using `apply`. You only still need to use `function(){}` for generators and custom constructors, which are rare.
« this » is « the thing on the left side of the dot ».<p>(that’s not always true, nor a complete definition - but it helps me a lot in understanding the whole thing)
This example is needlessly confusing:<p><pre><code> const a = {
b: 42,
c: function() {
return this.b;
}
};
(a.c || [])(); // 1
(a.c)(); // 2
(1, a.c)(); // 3
</code></pre>
He's trying to illustrate that an expression returns a reference to the (unbound) function. This line "(a.c || [])()" is bothering me -- why on earth would this line exist in any program? Are we trying to throw a type error on purpose? Maybe "(a.c || (()=>{}))()" would have been more appropriate.<p>I spent about 5 minutes wondering why each line returned 1, 2 and 3 respectively, when they should be returning the global value of b. If you are going to be showing obscure, tricky examples of Javascript, the last thing you want to do is have superfluous comments in your code. <i>Follow comment conventions</i> for the sake of your readers' sanity. This would have been much less confusing:<p><pre><code> const a = {
b: 42,
c: function() {
return this.b;
}
};
(a.c || (() => {}))(); // undefined
(a.c)(); // undefined
(1, a.c)(); // undefined</code></pre>
It's really frustrating that the ECMA people didn't define class methods to always be bound just like arrow functions. Like arrow functions, classes are a new syntax so there are no backward compatibility concerns.<p>That said, having two different semantics based on which syntax you happened to use to define a function is almost as big a programmer trap as the original problem. It just goes to show there are no good solutions to fundamental language design errors.
The answer to every question in this article, and any 'quiz' on how to use the arbitrary and ridiculous 'this' in JS is simple: use TypeScript.
Not knowing this 8 years ago in interviews was the same disqualifying as not knowing nowadays what is the latest Angular version and why is it incompatible with the previous version. The difference is that "this" is still relevant - just hit F12, enter "this", and hit <ENTER>.