Fat arrow inconsistency between Aurora 33.0a2 (2014-08-24) and Canary 39.0.2135.0 canary (64-bit)

inconsistency.js

var a = true;
var test = () => console.log(this.a);

test(); // true

var test2 = test.bind({ a: false });

test2(); // Canary: false, Firefox: true

for what it matters, this is the difference between the previously proposed thin arrow -> VS fat arrow => … Chrome gives you there the thin behavior (probably due missing "use strict" directive) which I personally believe is the most expected one from every JS developer, but fat behavior landed in specs instead so that Firefox result represents the right scenario/behavior.

This has been addressed many times already and here the result:

1. do not use fat arrow to define prototypes or objects method, they'll be bound to the non-meant/misleading/confusing outer context
2. do not use fat arrows for listeners, you'll end up being unable to remove them later on without a reference
3. do not use fat arrow for anything that should be polymorphic or mixin related, 'cause these will fail with the intent, being already bound

So what are fat arrows good for? Good question …

1. to tell developers that creating N callbacks at runtime inside other methods is good
2. to make runtime Promise like behaviors easier to read without needing to see if it was bound or not at the end of the then
3. nothing else, IMO … I've honestly no idea why in a world where .bind() exist ES6 decided to trick all JS developers with something that is half useful and for few very specific cases that are 30% of common JS usage but that's it, enjoy the fat arrow.

must be noted: apparently the -> thin arrow might land in ES7 … I still don't know why an already defined behavior as regular function is didn't make it in ES6 but seems like good news or something to re-clarify whenever this dual syntax will be implemented.

Thanks to @rwaldron for this info I've missed between discussions.

FWIW if you're defining object methods, the new shorthand syntax isn't too bad:

let obj = {
    method() { return this.foo + 7; }
};

Sure, unlike the proposed thin-arrow, it only eliminates the fiendish function and not the revolting return or the painful parens, but it isn't too far from

let obj = {
    method: () -> this.foo + 7;
};

Basically, devs were moaning that they lose context all the time, so they got fat arrow. Now we'll have the option to moan we can't lose context.

I find fat arrow great for use in filter/map/reduce. And binding to the outer context is natural in these cases, although I still avoid using this inside such callbacks.

Stay calm, learn the quirks, move on. Just like we've always done.

@webbedspace yes, that's nice … the point is that wasn't needed. Two different new Syntax instead of a thin arrow that could shave been used for both cases and for filter/map/reduce as @dymonaz said, probably forgetting that most Array extras accept already a second argument to be passed as context so that .filter((k) -> this[k], context) would have produced the same.

Thin arrow was the universally adaptable shortcut solution, we've got new syntax for methods and an often misleading/unexpected fat arrow instead … but "no time to shortcut just function".

Weird decision, IMO

I presume the author is testing this by enabling "experimental JavaScript features" in Canary. Such features are experimental and not meant to reflect actual usable up-to-spec JavaScript. Comparing them against Firefox's on-by-default features is not a fair comparison.

Also on an unrelated note the correct counterpart to Canary is Nightly; the correct counterpart to Aurora is Dev Channel.

@webbedspace -
Regarding -

let obj = {
    method: () -> this.foo + 7
};

(I removed the semicolon, as it would probably throw a SyntaxError)
I think this would be window in this case.
Just like -

this.foo = "r";
let obj = {
    bar: this.foo
};

Would be {bar: "r"}.

Am I wrong?

@phistuck pay attention to the arrow, the thin one does not bind the context at creation time. this would be the expected object in that method.

Wow, for some reason I got no notifications for this thread. Sorry all. @domenic is quite right. This was me looking at an experimental feature, and I was jumping the gun somewhat. Fat-arrows are only partially implemented in the version of V8 in that version of Canary and full support will come in time.

The two versions were not picked to be equivalent in terms of their development process. They just happened to be the browsers I was testing with.