Live data from Hacker News

Fat arrow functions in Javascript

robcee.net

11–20 of 48 posts

Re: Fat arrow functions in Javascript

#12
post #9
post #8

While this is pretty cool, I'm not really a fan of this. There is less to type, but I end up spending more time reading what the code is doing since there's more than one way to do it. (With optional parens, optional braces, and special syntax for returning objects in a single line). I would have preferred a different function keyword that had lexical this binding.

Not sure I agree with you. After using them for a few months, they feel pretty natural, light-weight and used close to where you define them. There's actually less thinking required when using a fat-arrow function because you don't really have to worry about the scope.

I have to agree.

I code in C#. I often grouse about certain cases where we use characters instead of words - particularly in boolean logic (I find SQL code with AND and OR and NOT far more readable than C-ish characters)... and especially since the => operator is a perversion of comparison... I mean, it feels like a backwards less-than-or-equal.

But after diving headlong into C#'s various lambda and LINQ features, it's become quite natural, at least for cases where you're creating a function in-line as an argument to another call.

If I were coding more Javascript? I'd probably deprecate the function() syntax with its "this" re-binding misfeature altogether.

Re: Fat arrow functions in Javascript

#13
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 normal scope chain (I think). The idea being that JS is doing fewer things in the background and makes functional programming a little easier on the CPU.

Re: Fat arrow functions in Javascript

#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 saved. And yet the mental overhead of a whole new syntax is introduced, which developers can now encounter in the wild.

"The real benefit of course is that you don’t have to go through the mental hoop-jumping of trying to figure out what scope your function is going to run in (and more often-than-not, you just wanted it to run inside the current scope the function is being defined in anyway)."

The amount of mental hoop-jumping recalling more language features and what they do outweighs this. I can understand if something is really used all the time. But when something is already a pattern that's pretty straightforward to type, do we really need another lexical element, which differs in obscure semantic details like "you can't override the this variable" and other things?

I would argue that languages which are "easy to learn, tough to master", like Chess, are best for programming large projects.

Re: Fat arrow functions in Javascript

#16
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…

Let's also note that even though "=>" contains fewer characters than "function", it is arguably more difficult to type, since it requires a jump to the top row of keys for "=", and the shift key for ">".

Re: Fat arrow functions in Javascript

#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 before I can understand this article?

Re: Fat arrow functions in Javascript

#18
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...

Re: Fat arrow functions in Javascript

#19
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…

You can use Function.prototype.bind instead of creating a closure. Check out the examples here: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Re: Fat arrow functions in Javascript

#20
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.

Post reply on HN