Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

“This” in JavaScript

bjorn.tipling.com

Post reply on HN
Print view View original

11–20 of 99 posts

Re: “This” in JavaScript

#11

Post by nmjohn »

> JavaScript is not such a language. ... There are many “gotchas”

I don't disagree, like all languages javascript has its quirks (more than some, fewer than others, all depending on a given developers perspective) but I fail to see this conclusion being supported by the article itself.

Basically every quirk in it was a result of 'use strict' preventing a developer from leaking variables (and thus `this`) in ways they shouldn't be doing - which results in slightly different behavior when strict mode is enabled. The only real quirk I see here is the fact that strict mode isn't enabled by default (or better yet not even an option to turn off) but that is because it would kill backwards compatibility.

'this' in actuality is pretty straightforward - unless you make it complex. (Which javascript does make it very easy for you to do, which means bad code will be written doing just that. But bad code is bad code regardless.)

When you define a new function, the contents will have a different scope and 'this' will be different. If you want to access the parent this in a nested function, you either call the function with the 'this' bound, or you do `var self=this;` in the parent scope, and use 'self' in lieu of 'this'.

That is pretty much it - I can see how it is a bit tricky at first, but after spending a bit of time working on javascript it really isn't something you have to consciously think about too often.

I don't think it is inherently bad, just different. Back when I was writing Java I would have told you I like their approach better, but now after writing almost exclusively javascript for the last year or so, I would say I like the javascript 'this' better. At the end of the day they are just different and a developer needs to learn the intricacies of whichever language they are developing in. (Since criticizing javascript is trendy on hn these days, if you want something to be critical of javascript about that can objectively be explained, go with the lack of static typing or the related quirky type coercion in equality checking resulting in (2 == [2]) => true.)

Re: “This” in JavaScript

#12

Post by _RPM »

I skimmed the article. I began to get anxiety once I realized how long it was. JavaScript is a very simple language. `this` in JavaScript is easy to understand. Long posts like this give me anxiety.

Re: “This” in JavaScript

#15

Post by TazeTSchnitzel »

_RPM wrote: post #12

I skimmed the article. I began to get anxiety once I realized how long it was. JavaScript is a very simple language. `this` in JavaScript is easy to understand. Long posts like this give me anxiety.

It's like an exhaustive, confusing list of examples rather than explaining briefly the very simple and largely intuitive reasons that lead to these examples.

Re: “This” in JavaScript

#16

Post by couchand »

The author critically misunderstands the way that `this` gets set, and in doing so has developed a significantly overcomplicated mental model. This is exemplified in the statement:

You can use this in any function on an object to refer to other properties on that object. This is not the same as an instance created with new. ... Note, there was no use of new , no Object.create and no function called to create obj.

This is exactly the same behavior that you see on an object method reference, and drawing any distinction at all makes understanding the behavior of this harder than it needs to be.

In nearly every case (with the exception of bind, call and apply) the this variable is set at the CALL SITE of the function, NOT THE DEFINITION. Note that in the three other cases, you still aren't setting this at the definition.

The reason you get this behaving as the author describes on objects created with new is only (as the author nearly, but not quite, realizes) because you called the function in the form:

    thing.method()
Specifically, it is the object reference that sets the this context within the method call.

You can be sure that the object literal case is just the same. You don't need to call new to get an object reference that has a prototype chain: namely, an object literal is instantiated with the prototype Object. You can verify this is true with a simple:

    thing = {}
    thing.hasOwnProperty === Object.hasOwnProperty
...and so forth.

Re: “This” in JavaScript

#17

Post by TazeTSchnitzel »

This post is way, way too long. Rather than explaining the simple principles that lead to the behaviour JS's this has, the post just lists example after example.

JS 'this' is a variable defined within a function. If that function is called as if it were a method, e.g. obj.somefunc(), 'this' is that object, obj. Otherwise, 'this' is the global object (quirks mode) or undefined (strict mode). If a function is called with the new keyword, 'this' is set to a new object whose prototype is set to the property named 'prototype' on the function.

The prototype of an object is a fallback: if you try to read a property on an object and it lacks such a property, it'll grab it from its prototype (or its prototype's prototype etc.) if it has it. If you write to or create a property on an object, it always goes on the object and won't touch the prototype.

The weird behaviour for DOM events isn't weird. It just calls the onclick method as a method.

Re: “This” in JavaScript

#20

Post by [deleted] »

couchand wrote: post #16

The author critically misunderstands the way that `this` gets set, and in doing so has developed a significantly overcomplicated mental model. This is exemplified in the statement: You can use this in any function on an object to refer to other properties on that object. This is not the same as an instance created with new. ... Note, there was no use of new , no Object.create and no function called to create obj. Thi…

[deleted]
Post reply on HN