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

Fat arrow functions in Javascript

robcee.net

Post reply on HN
Print view View original

31–40 of 48 posts

Re: Fat arrow functions in Javascript

#31

Post by EGreg »

rybosome wrote: post #28
EGreg wrote: post #14

I am not pleased at seeing language bloat. Look at what happened with C++11. Languages are supposed to give a common base for developers to read and write the same code. New developers should be able to get up to speed quickly, and see the intent of the other developers, which is one of the reasons Linux is written in C instead of C++. "Look at all that saved typing!" Yeah, shockingly there were only a few characters…

I understand your sentiment in general, but disagree in this particular case. I've been writing JavaScript for years in various projects, companies, partnerships, etc. If I had a nickel for every time I saw... asyncOperation(_.bind(function(x) { this.x += x; }, this)); or... asyncOperation(goog.bind(function(x) { this.x += x; }, this)); or... asyncOperation(function(x) { this.x += x; }.bind(this)); or... asyncOperati…

Well, in this particular case I agree. If an operation is very commonly used, and/or it can allow major compiler/interpreter optimizations by doing it at the language-level instead of a library level, then you should put it into the language.

But this is not the case for SO MANY constructs. Especially in a language like PHP, where they've recently added even more stuff that very few people would care about.

Re: Fat arrow functions in Javascript

#32

Post by hyperpape »

ebiester wrote: post #20
EGreg wrote: post #14

I am not pleased at seeing language bloat. Look at what happened with C++11. Languages are supposed to give a common base for developers to read and write the same code. New developers should be able to get up to speed quickly, and see the intent of the other developers, which is one of the reasons Linux is written in C instead of C++. "Look at all that saved typing!" Yeah, shockingly there were only a few characters…

I think that => is going to be used far more than you think. The original scoping rules for javascript have caused all sorts of confusion. The important piece isn't removing function, it's removing .bind(this). The changes in ES6 go a long way in making modern javascript more intuitive to write.

I agree that the way scope works in fat arrow functions is better, and I'm honestly excited about most of ES6 (proper maps and sets alone are worth it to me).

What does make me sad is that the old shit isn't going away. And not that it's not going away soon, but that, as far as we can tell, we're going to be teaching people about "this" for the rest of eternity.

I get why Brendan Eich and others are scared of versioning javascript, but I don't think it's tenable to have to keep so many semantically dischordant features of the language around for decades.

Re: Fat arrow functions in Javascript

#34

Post by tieTYT »

armandososa wrote: post #18
tieTYT wrote: post #17

This article is written for someone who already understands the old issue that this is fixing (there's nothing wrong with writing it like that). But for someone like me that doesn't understand when you need to use this `bind()` stuff and the context your function is in (if I'm even saying that correctly), what can I read to get a better understanding of what's going on here? In other words, what do I need to read bef…

this is a good start http://yehudakatz.com/2011/08/11/understanding-javascript-fu...

Great link, that really clarified things for me (I think). The OP article uses this sample as something you can do with fat arrows. "Because the containing scope closes over the fat arrow function, you can do things like,"

    let fib = (n) => {
        if (n
I don't understand what this is showing. Wouldn't this code work the same way without fat arrows because there's no `this` being used anywhere?

Re: Fat arrow functions in Javascript

#35

Post by ax »

graue wrote: post #27

Did anyone else do a double take reading this? > If you’re a JavaScript programmer, chances are you’ve seen (and done) something like this before: var listener = node.addEventListener("click", function(event) { let _target = event.target; this.handleClick(_target); }.bind(this)); I had to go look up `let` in JavaScript[1]. It appears to still be a bleeding-edge feature not widely supported[2] outside of Firefox... no…

Both let and const are supported in IE11 as well!

Re: Fat arrow functions in Javascript

#36

Post by ax »

_greim_ wrote: post #13
ender7 wrote: post #5

First and probably most useful is that they gain the lexical scope of the environment they’re defined in. Nit: technically, all Javascript functions are lexically scoped. The fat arrow permanently binds the value of "this", which is sort of like modifying the scope, but again not technically because "this" is a special keyword and not a variable.

> The fat arrow permanently binds the value of "this" I'm still trying to understand the details here, but my impression is that ()=>{} isn't a shorthand for function(){}.bind(this). The latter creates two functions, one with an auto-bound "this" and another with a manually-bound "this". The former creates one function, skipping the step of auto-binding a new "this" to it. So it just sees the outer "this" via the nor…

Each function has its own this binding - the conceptual model for this is that its an implicit argument to every function call. There is no scope chain lookup for "this". Although, there is no way to observe any difference between your understanding of the semantics or the bind semantics (which is a valid desugarding AFAIK) so the distinction is mostly moot...

Re: Fat arrow functions in Javascript

#37

Post by v413 »

ender7 wrote: post #5

First and probably most useful is that they gain the lexical scope of the environment they’re defined in. Nit: technically, all Javascript functions are lexically scoped. The fat arrow permanently binds the value of "this", which is sort of like modifying the scope, but again not technically because "this" is a special keyword and not a variable.

The "this" value in functions is not lexically scoped. It is determined during function invocation, not during function declaration.

Re: Fat arrow functions in Javascript

#38

Post by rybosome »

EGreg wrote: post #31
rybosome wrote: post #28

Earlier quoted context omitted.

I understand your sentiment in general, but disagree in this particular case. I've been writing JavaScript for years in various projects, companies, partnerships, etc. If I had a nickel for every time I saw... asyncOperation(_.bind(function(x) { this.x += x; }, this)); or... asyncOperation(goog.bind(function(x) { this.x += x; }, this)); or... asyncOperation(function(x) { this.x += x; }.bind(this)); or... asyncOperati…

Well, in this particular case I agree. If an operation is very commonly used, and/or it can allow major compiler/interpreter optimizations by doing it at the language-level instead of a library level, then you should put it into the language. But this is not the case for SO MANY constructs. Especially in a language like PHP, where they've recently added even more stuff that very few people would care about.

That's fair. If language developers were willing to deprecate more aggressively, it wouldn't be such a problem...but every hacked-up, shoehorned feature represents a major investment that must be tended to for years.

Re: Fat arrow functions in Javascript

#39

Post by iMark »

robcee wrote: post #29
graue wrote: post #27

Did anyone else do a double take reading this? > If you’re a JavaScript programmer, chances are you’ve seen (and done) something like this before: var listener = node.addEventListener("click", function(event) { let _target = event.target; this.handleClick(_target); }.bind(this)); I had to go look up `let` in JavaScript[1]. It appears to still be a bleeding-edge feature not widely supported[2] outside of Firefox... no…

I was aware it's pretty modern but honestly didn't think about it much. We use it heavily in Firefox Devtools code and I much prefer its non-hoisting properties over var.

Out of curiosity, what do you mean by non-hoisting properties? According to the MDN docs let variables are hoisted, at least to the enclosing block.
Post reply on HN