
Arrow Functions Coming to Chrome 45 - apaprocki
https://wingolog.org/archives/2015/06/18/arrow-functions-coming-to-chrome-45
======
0x0
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?

~~~
owencm
We try and make sure that the Chromium blog
([http://blog.chromium.org/](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.

~~~
0x0
Awesome, thanks!

------
egeozcan
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:

    
    
        (
          (
            {},
            {},
            ({},{})=>({},{})
          )=>
          (({},{})=>({},{}),{},{})
        )({},{})
    

I can rewrite that to be more clear:

    
    
        //(({},{})=>({},{}),{},{}) evaluates to {}
        //({},{}) evaluates to {}
        let fn = ({}, {}, ({},{})=>{}) => {};
        fn({},{});
    

This is just a syntax error, I guess (hope)?

~~~
SerpentJoe
It is. You can try to translate the snippet using babel, it doesn't work
unless you remove that parameter.

------
moron4hire
> 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`.

~~~
ubertaco
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.

~~~
moron4hire
ok, that makes sense. Yes, `arguments` is a shitty replacement for real
varargs.

------
fenomas
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..

~~~
chenglou
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.

~~~
fenomas
Sure, but that's all true regardless of the Chrome update discussed in the
article. That's what I was wondering about.

------
homulilly
I take it this means we'll also get arrow functions enabled by default in
IO.js shortly?

------
apalmer
No Offense, but arrow functions and the 'let' keyword in particular just seem
like really bad ideas for javascript.

~~~
paublyrne
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.

~~~
apalmer
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'.

~~~
spb
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.

