Is this syntax part of ECMAScript 6? I.E. will it eventually be supported by all browsers?
it is part of ES6 and should make it to V8 eventually. Soon, I hope!
Fat arrow functions in Javascript
11–20 of 48 posts
Re: Fat arrow functions in Javascript
#12While 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 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
#13First 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.
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"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
#15Re: Fat arrow functions in Javascript
#16I 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…
Re: Fat arrow functions in Javascript
#17In other words, what do I need to read before I can understand this article?
Re: Fat arrow functions in Javascript
#18This 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…
Re: Fat arrow functions in Javascript
#19This 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…
Re: Fat arrow functions in Javascript
#20I 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…
The changes in ES6 go a long way in making modern javascript more intuitive to write.