ES6 in Chromium Proposal: => (arrow)

[Dan Beam]

Feature:
Allow => (arrow) functions.

Overview:
=> is a concise way to express functions without changing scope (a super common, hard-to-detect pitfall).

Style guide section:

https://chromium.googlesource.com/chromium/src/+/master/docs/es6_chromium.md#Arrow-Functions

Details:
Example code like this is error prone and laborious (to set up the right |this| in every scope):

setTimeout(function() {

  if (this.hasThePower_) {  // silently fails on wrong |this|

    this.startWarpDrive_(function(speed) {

      assert(speed == this.TOP_SPEED_);

    }.bind(this));

  }

}.bind(this));  // if .bind(this) is omitted, bad things happen

An example that uses => is a lot nicer and harder to screw up:

setTimeout(() => {

  if (this.hasThePower_)

    this.startWarpDrive_(s => assert(s == this.TOP_SPEED_));

});

In my experience, |this| seems to be fairly hard to figure out at compile time, so it's unlikely closure compiler or other typecheckers do an amazing job detecting what |this| is and breaking early on issues.

=> is really useful for concise lambdas, which in common in filtering or mapping by key.  Example:

var people = [{name: 'Waldo'}, {name: 'Wenda'}];

// Found Waldo!

people.find(p => p.name == 'Waldo').found = true;

var missing = people.filter(p => !p.found).map(p => p.name);

// ['Wenda'] is missing.

Possible Issues:

Disagreement around when to use optional () around single param or {} when return not required.

(a) => {return [];}  // equal to: a => []

My opinion: optional parens are discouraged in Google ES5 style guide (i.e. return(1);), and braces are often discouraged for simple conditionals, so I'd drop both () and {} in these cases.

Compatibility:
Support in environments we care about (Chrome, iOS, node?) looks good, as far as I can tell:

http://caniuse.com/#feat=arrow-functions

http://node.green/#arrow-functions

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/Arrow_functions#Browser_compatibility

Performance:
Somebody smart told me it's pretty much free (like as fast as function() {}).

Tooling:

TBD, probably blows up some things as it's new syntax (almost certainly closure linter, which we're trying to phase out anyways).  Ready to start looking into this if we agree we want it.  Happy to send patches or file issues.  Confident we'll get the support we need or find better tools ;).

tl;dr - What does everybody think?

-- Dan

[PhistucK]

Issue - supported on iOS 10 only... Chrome supports iOS 9 as well.

Otherwise, very convenient.

By the way, checking compatibility status at http://kangax.github.io/compat-table/es6/ is probably better.

☆PhistucK

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev+unsubscribe@chromium.org.

[Richard Maher]

"Please, stop going off topic in this group. This is a development group, not a standards body, or anything else that is related to *proposing* platform ideas."

Can we please apply the same rules to all equally in future?

☆PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.

[PhistucK]

This is related to Chromium development. Some code is written in JavaScript and the style guide/features to use topic is totally development related.

(Also, there was a question earlier regarding creating a new group for JavaScript feature suggestions and no one replied that it should be created.)

And Dan is a Chrome team member, I think he knows the rules of the group.

I am sorry if you were insulted earlier when I replied to you with that note, but you should be on topic. Many people are subscribed to this group and are unnecessarily getting off topic thread to their inboxes.

☆PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev+unsubscribe@chromium.org.

[PhistucK]

To clarify - those feature proposals are not platform ideas - they are existing (but new) platform features that are suggested to be used within the Chromium code base.

☆PhistucK

[Peter Kasting]

On Wed, Dec 14, 2016 at 1:59 AM, 'Richard Maher' via Chromium-dev <chromi...@chromium.org> wrote:

"Please, stop going off topic in this group. This is a development group, not a standards body, or anything else that is related to *proposing* platform ideas."

Can we please apply the same rules to all equally in future?

This isn't a proposal of a platform idea.  This is about modifying the Chromium JS style guide to allow use of an existing platform feature within Chromium code itself.

This is multiple times today when you've been snarky in public on this list where it turned out the source of your snark was operator error.  Snarkiness is something we're trying to clamp down on regardless, and doubly so if there's no actual justification for a disagreement to begin with.

You have been asked nicely already in the past to abide by our code of conduct.  I am turning that into a public warning.  Please be careful about what you say here, or we will need to take action.

I am sorry if this makes you feel persecuted.  You are still welcome here, and I hope things stay that way.

PK

[Devlin Cronin]

+1; arrow functions will help a lot.  Your suggestions re when to use () and {} sound good.  As PhistucK mentioned, there might be some issues on iOS, so there arises the question of whether or not we're okay with saying "We can use these everywhere except here."

One other concern: I know that in the past the v8 team has mentioned certain ES6 features are slower than their <=ES5 counterparts; have we asked which features those are (if that's still the case for any - maybe they've all been fixed), and documented somewhere that we should avoid using those in extremely performance-sensitive code?  (Hopefully with bugs that can be fixed and then places updated?)  I imagine the number of places that this will be important in chromeJS is relatively small, but probably >0.

[Yuri Wiitala]

+1

Having written 1000s of lines of JS code recently (both ways), the arrow syntax is much cleaner, concise, and sane w.r.t. scoping rules; especially with our callback-heavy API style, and when using Promises. More readable code, less bugs...what's not to like? In fact, we should probably say something to the effect of "prefer using the arrow syntax for anonymous functions."

2016/12/14 午前8:23 "Devlin Cronin" <rdevlin...@chromium.org>:

--

[Dan Beam]

On Wed, Dec 14, 2016 at 11:37 AM, Yuri Wiitala <m...@chromium.org> wrote:

+1

Having written 1000s of lines of JS code recently (both ways), the arrow syntax is much cleaner, concise, and sane w.r.t. scoping rules; especially with our callback-heavy API style, and when using Promises. More readable code, less bugs...what's not to like? In fact, we should probably say something to the effect of "prefer using the arrow syntax for anonymous functions."

The Google ES6 style guide did this and it was a little too highly encouraged, IMO (people started saying "function is banned!").  We can make the wording stronger over time if we'd like.  Right now I think they can co-exist with a clear explanation of why => is better in the style guide.

 

2016/12/14 午前8:23 "Devlin Cronin" <rdevlin...@chromium.org>:

+1; arrow functions will help a lot.  Your suggestions re when to use () and {} sound good.  As PhistucK mentioned, there might be some issues on iOS, so there arises the question of whether or not we're okay with saying "We can use these everywhere except here."

One other concern: I know that in the past the v8 team has mentioned certain ES6 features are slower than their <=ES5 counterparts; have we asked which features those are (if that's still the case for any - maybe they've all been fixed), and documented somewhere that we should avoid using those in extremely performance-sensitive code?  (Hopefully with bugs that can be fixed and then places updated?)  I imagine the number of places that this will be important in chromeJS is relatively small, but probably >0.

Like I mentioned earlier in Performance, I believe => to be fast already.  [+adamk@, bmeurer@, mstarzinger@]

I'll let this thread continue to bake, but in the meantime I've posted a presubmit that checks for => in .js files that might run on iOS9 (where => doesn't work).  Seemed like a good idea independent of this thread:
https://codereview.chromium.org/2576253002/

-- Dan

[Adam Klein]

On Thu, Dec 15, 2016 at 1:22 AM, Dan Beam <db...@chromium.org> wrote:

On Wed, Dec 14, 2016 at 11:37 AM, Yuri Wiitala <m...@chromium.org> wrote:

+1

Having written 1000s of lines of JS code recently (both ways), the arrow syntax is much cleaner, concise, and sane w.r.t. scoping rules; especially with our callback-heavy API style, and when using Promises. More readable code, less bugs...what's not to like? In fact, we should probably say something to the effect of "prefer using the arrow syntax for anonymous functions."

The Google ES6 style guide did this and it was a little too highly encouraged, IMO (people started saying "function is banned!").  We can make the wording stronger over time if we'd like.  Right now I think they can co-exist with a clear explanation of why => is better in the style guide.

 

2016/12/14 午前8:23 "Devlin Cronin" <rdevlin...@chromium.org>:

+1; arrow functions will help a lot.  Your suggestions re when to use () and {} sound good.  As PhistucK mentioned, there might be some issues on iOS, so there arises the question of whether or not we're okay with saying "We can use these everywhere except here."

One other concern: I know that in the past the v8 team has mentioned certain ES6 features are slower than their <=ES5 counterparts; have we asked which features those are (if that's still the case for any - maybe they've all been fixed), and documented somewhere that we should avoid using those in extremely performance-sensitive code?  (Hopefully with bugs that can be fixed and then places updated?)  I imagine the number of places that this will be important in chromeJS is relatively small, but probably >0.

Like I mentioned earlier in Performance, I believe => to be fast already.  [+adamk@, bmeurer@, mstarzinger@]

Arrow functions are syntactic sugar: they come with no runtime overhead compared to classic function expressions.

As for the general issue of ES6 performance vs ES5 counterparts, that's something V8 team is fairly focused on at the moment (and we have a doc with some more details at https://docs.google.com/document/d/1EA9EbfnydAmmU_lM8R_uEMQ-U_v4l9zulePSBkeYWmY/edit). I'm happy to answer questions about specific features as they come up during this process.

[Torne (Richard Coles)]

Not saying I don't believe you that they have no runtime overhead (I can imagine how this could easily be the case in the VM), but they're not really syntactic sugar are they? They set [[ThisMode]] to lexical, which you can't do with a function expression..

--

[Adam Klein]

Sure, there are lots of details here. I'll leave it at "there should be no runtime overhead" :)

[Dan Beam]

I haven't heard any substantial objections, so I'm going to move => to the Allowed Features list in the style guide.

I'm also thinking about doing some [semi-]automated refactoring to move .bind(this) to use =>.  I started prototyping here.

I've noted caveats of => in the ES6 style guide, but I'll also add them here.

• (permanent) => does not work on iOS9
  

I've added a presubmit that looks for => in code I believe to be potentially run on iOS9. (currently: ios/, ui/webui/resources, and components/).

• (temporary) => is not supported in the NPM version of uglifyjs
  

This only affects downloads and history and can be fixed with `npm install -g https://github.com/mishoo/UglifyJS2#harmony`.  Still thinking about whether this is a good idea.  If it is, I'll add it to the vulcanize doc.

For what it's worth, I tried the node-based version of Closure Compiler today to see if we could use it instead of uglifyjs, but it was blowing up.

• (temporary) => is not recognized by closure_linter

We should've dropped the linter for clang-format (which supports =>) ages ago.  Soooo, I'm doing that.

-- Dan

[Yuzhu Shen]

On Wed, Dec 21, 2016 at 6:38 PM, Dan Beam <db...@chromium.org> wrote:

I haven't heard any substantial objections, so I'm going to move => to the Allowed Features list in the style guide.

I'm also thinking about doing some [semi-]automated refactoring to move .bind(this) to use =>.  I started prototyping here.

I've noted caveats of => in the ES6 style guide, but I'll also add them here.

• (permanent) => does not work on iOS9
  

I've added a presubmit that looks for => in code I believe to be potentially run on iOS9. (currently: ios/, ui/webui/resources, and components/).

Please also include mojo/public/js and mojo/public/tools/bindings/generators/js_templates/*.tmpl (which are used to generate mojo JS bindings).

[PhistucK]

On Thu, Dec 22, 2016 at 4:38 AM, Dan Beam <db...@chromium.org> wrote:

but it was blowing up.

​Can you be a bit more detailed (and did you file a bug?)? :)​

☆PhistucK

[Dan Beam]

On Thu, Dec 22, 2016 at 8:47 AM, PhistucK <phis...@gmail.com> wrote:

On Thu, Dec 22, 2016 at 4:38 AM, Dan Beam <db...@chromium.org> wrote:

but it was blowing up.

​Can you be a bit more detailed

☆PhistucK

The details are that... uglifyjs 2.4.10 (latest in NPM) doesn't work with ES6.  It just doesn't recognize new syntaxes like => or for ( of ).  There's a branch called "harmony" that generally works, but still has some blocking-scoping issues (source).

(and did you file a bug?)? :)​

I figured the 28 results for "harmony" and 35 results for "ES6" probably had me covered.

When I switch to the harmony branch, I don't have issues, but I also can't freeze the code to ensure all team members get uglifyjs with the same code.  That's a bit of a problem.  I'm also not stoked on the number of open bugs on the harmony branch.

-- Dan

[PhistucK]

Sorry for the missing context, I referred to your Closure Compiler experience, not the UglifyJS one. Here is the fuller one -

> For what it's worth, I tried the node-based version of Closure Compiler today to see if we could use it instead of uglifyjs, but it was blowing up.

Can you be a bit more detailed (and did you file a bug?)? :)​

☆PhistucK