Arrow Functions Coming to Chrome 45(wingolog.org)
wingolog.org
Arrow Functions Coming to Chrome 45
https://wingolog.org/archives/2015/06/18/arrow-functions-coming-to-chrome-45
6 comments
Why is it that all new chrome features are usually announced on random blogs all over the place, while the official "chromereleasenotes" blogspot blog has almost never any useful information? There they all seem to talk about various minor security fixes in the stable channel posts, but almost never are new features highlighted. Is it really necessary to track the beta and canary release notes and svn logs to stay on top of things?
Because individual devs with "random blogs" know about actions they've taken sooner than its filtered into official corporate announcements.
> There they all seem to talk about various minor security fixes in the stable channel posts, but almost never are new features highlighted. Is it really necessary to track the beta and canary release notes and svn logs to stay on top of things?
New JS features and the like seem to be announced on the chromium blog (not the chrome releases blog), but often only with Beta releases. 45 hasn't hit Beta yet, so...
But the most complete official source of information on feature status isn't a blog, its https://www.chromestatus.com/features
> There they all seem to talk about various minor security fixes in the stable channel posts, but almost never are new features highlighted. Is it really necessary to track the beta and canary release notes and svn logs to stay on top of things?
New JS features and the like seem to be announced on the chromium blog (not the chrome releases blog), but often only with Beta releases. 45 hasn't hit Beta yet, so...
But the most complete official source of information on feature status isn't a blog, its https://www.chromestatus.com/features
We try and make sure that the Chromium blog (http://blog.chromium.org/) always covers new features as they make it into the new Beta. Imho you should be able to read the beta blog posts on that blog and not miss any new developer shiny things. Also fwiw we're going to try and do a better job of making the release notes link to the appropriate beta blog post on the Chromium blog, I agree we've done a poor job on that in the past.
Awesome, thanks!
Regarding the example at the end of the post, how does it even make sense to allow an anonymous arrow function be a "paramater name" (yes!) of another anonymous function? I guess the empty object becomes a destructuring parameter that doesn't do anything but the function is confusing:
(
(
{},
{},
({},{})=>({},{})
)=>
(({},{})=>({},{}),{},{})
)({},{})
//(({},{})=>({},{}),{},{}) evaluates to {}
//({},{}) evaluates to {}
let fn = ({}, {}, ({},{})=>{}) => {};
fn({},{});
It is. You can try to translate the snippet using babel, it doesn't work unless you remove that parameter.
> Relative to the other kind of function that is written like function (x) { return x * 2 }, arrow functions don't define this or arguments in their bodies, instead capturing these values from the environment.
In the case of `this`, I can see why they did that: it is the right semantics and all of JavaScript should be this way. But I really think creating two different behaviors for what should all just be syntactic sugar around the same, ol' function values is long-term going to reveal itself as a mistake.
But that's just `this`. I can't for the life of me imagine why they also did this for `arguments`.
In the case of `this`, I can see why they did that: it is the right semantics and all of JavaScript should be this way. But I really think creating two different behaviors for what should all just be syntactic sugar around the same, ol' function values is long-term going to reveal itself as a mistake.
But that's just `this`. I can't for the life of me imagine why they also did this for `arguments`.
I think that was largely to make it easier to deal with arrow functions in higher-order functions, though the only case I can see for "arguments" anymore is for varargs, and those are covered with the rest operator, so I'm not sure why the distinction is made.
ok, that makes sense. Yes, `arguments` is a shitty replacement for real varargs.
The author says using arrow functions won't hurt performance, but I wonder if that means v8 knows how to optimize them?
Last I checked, using any ES6 syntax causes v8 to permanently deopt the containing function - even using let/const to declare an unused variable that would get removed as dead code. It'll be great once that starts changing..
Last I checked, using any ES6 syntax causes v8 to permanently deopt the containing function - even using let/const to declare an unused variable that would get removed as dead code. It'll be great once that starts changing..
As of today, Babel turns arrow down to normal anonymous function, and wires up the `this` inside if there's any. So if you compile through Babel (and we'll probably keep compiling for another while) there's no overhead.
Sure, but that's all true regardless of the Chrome update discussed in the article. That's what I was wondering about.
I take it this means we'll also get arrow functions enabled by default in IO.js shortly?
No Offense, but arrow functions and the 'let' keyword in particular just seem like really bad ideas for javascript.
Arrow functions and `let` are what is generally considered to be the "correct" way of doing things. They behave more closely to how other languages behave, and should reduce overall confusion in the long term.
The arrow operator is indeed syntactic sugar for binding `this` to the function. It's not really necessary, but it makes it much easier to do what you expect to do 99% of the time.
Yes, it sucks that there are now two slightly different ways of doing things, but it's better than breaking all of the existing code currently in use. Hopefully, linters and analysis tools will mark `var` and non-arrow functions as deprecated soon after the major engines support ES6.
The arrow operator is indeed syntactic sugar for binding `this` to the function. It's not really necessary, but it makes it much easier to do what you expect to do 99% of the time.
Yes, it sucks that there are now two slightly different ways of doing things, but it's better than breaking all of the existing code currently in use. Hopefully, linters and analysis tools will mark `var` and non-arrow functions as deprecated soon after the major engines support ES6.
No offence taken, but what about let do you think is wrong for JavaScript? It will help make common scope errors less common, and is clean to read.
basically i feel like it greatly complicates the scoping rules in order to make javascript scoping similar to other languages scoping rules. If there was no 'var' I would be fine with 'let' and in theory perhaps 'let' is better than 'var', however if i had a choice between having both or having just one, i would rather just have either, even if the either is 'var'.
If you think of `var` as a syntactic sugar for a `let` declaration that gets hoisted to the top of its containing function, `let` actually simplifies scoping.
why? i'd say if es6 had only 2 features one should be at least => .
Arrow functions are worse, as far as I can tell the only benefit is to save a few characters of text. To get this win, now I have to always be conscious of how a function was created which syntax was used and as a result how 'this' was bound.
basically it is a 'fix' to a unusual but completely working and simple to reason about programming feature by adding a more correct but very inconsistent with the rest of the language that makes the whole thing harder to reason about.
does it serve any other benefit? I might be missing something as many people love this feature.
basically it is a 'fix' to a unusual but completely working and simple to reason about programming feature by adding a more correct but very inconsistent with the rest of the language that makes the whole thing harder to reason about.
does it serve any other benefit? I might be missing something as many people love this feature.
> does it serve any other benefit
Yes, as stated in the linked article:
> arrow functions don't define this or arguments in their bodies, instead capturing these values from the environment
Also:
https://hacks.mozilla.org/2015/06/es6-in-depth-arrow-functio...
Yes, as stated in the linked article:
> arrow functions don't define this or arguments in their bodies, instead capturing these values from the environment
Also:
https://hacks.mozilla.org/2015/06/es6-in-depth-arrow-functio...
When I'm working with C#, I often write code like so:
products
.Where(p => p.Price >= range.low && p.Price <= range.high)
.GroupBy(p => p.Category)
.Select(g => new { Category = g.Key.Name, Count = g.Count() })