Verbosity is not clarity.

    list.map(function(x) { return x * 2; });

verses

    list.map(x => x * 2);

The actual functionality of the first is swallowed in visual noise (function, return). Yes, it's something new to learn for Javascript programmers, but it's useful and makes the meaning of code clearer.

That's not even touching on the this-binding element, which is also incredibly useful in common Javascript code.

Just eliminating the words "function" and "return" doesn't make the code clearer. Anyone competent with Javascript can easily read the first form. The difference in time to read the expression may not even be measurable. If you want to argue that it makes the code neater that's fine, but the meaning is not made clearer by the substitution of sigils for words.

> Anyone competent with Javascript can easily read the first form

And anyone competent with any language implementing map can easily read:

    users.map(user => user.name);

...without having to do any "skimming over" the noise. It's not a big difference, you're right, but it's the kind of little thing that, when you let it build up over time, gives you the "write-everything-in-triplicate" feel of Java 6.

Further, you have to be intimately familiar with Javascript to understand why this is necessary:

    function fetchUserData(){
        var self = this;
        userService.fetchAllUsers()
                   .then(function(fetchedUsers){ self.users = fetchedUsers; });
    }

or even this:

    function fetchUserData(){
        userService.fetchAllUsers()
                   .then(function(fetchedUsers){ this.users = fetchedUsers; }.bind(this));
    }

as opposed to simply writing:

    function fetchUserData(){
        userService.fetchAllUsers()
                   .then(fetchedUsers => this.users = fetchedUsers);
    }

Did you know you can do this!?

  someObject.foo = function() {
    someObject.bar = 123;
  }

  function Foo() {
    var Foo = this;
    Foo.bar = 456;
  }

Pro tip: Always do asynchronous operations Before presenting the object to the program state. Or you will see "undefined" bugs in production!

As has been pointed out though, that is not the primary thing that arrow functions give you. They're really there to avoid having to manually bind functions in order to maintain execution context or use the old `var self = this; function(){/.../}` workaround.

I've been doing ES6 for several months now. Not once have I mistook `=>` for `>=`. Not once have I made a typo when I wanted an arrow function.

Of course any syntax can be abused in such a way to create ugly code. But if I compare

    [1, 2, 3].map( a => a * a );  // [1, 4, 9]

to

    [1, 2, 3].map(function(a) { return a * a; });

I prefer the former. It's more concise, and strips off a lot of visual noise, and I think it's more readable (the intent isn't wrapped in lots of boilerplate).

That doesn't mean one can't write horrible code with the arrow form. Of course you can. Furthermore, it's not necessarily something you should use all the time, because it's not completely analogous to a normal `function` because it binds `this` lexically. Which means `function` isn't going away any time soon, especially if you need to bind them dynamically.

In short: use the best (syntactic) tool for the job. There are use cases where the arrow makes sense semantically, and there are cases where it doesn't. Use as appropriate, as one should always do.

Actually that code example is hard to read because your variables are called 'foo' and 'a' and you've chosen not to include white space around your operators.

The lambda function is a foundational construct in computer science (1936), and it is often written using an arrow. Hipster fluff it is not.

You are trolling, but arrow functions (unlike those defined with the function keyword) also bind this to that of the enclosing scope. The results in more intuitive behavior in most cases and less explicit bindings.

shrug it's still just code. It still does exactly the same thing as previous javascript code. Syntax changes are pretty boring IMHO, and as I said personally, I find this one much harder to read, more prone to errors, typos and confusion.

You seem to keep missing that it has a different effect on scope and therefore you are incorrect in insisting it does "the same thing"

Also, your tone is bad.

At some point things have to stop being called "syntax changes". Just because you can represent the same operation by pressing more keys doesn't mean that it's not useful to add an abstraction on top of it to ease cognitive load, otherwise we'd all be programming with switches.

I think a better argument would have been that adding something that appears to just be a shorthand for writing functions is a potential footgun to language newcomers, but I think that argument is still relatively weak.

Then lets "abstract" your first sentience:

At point have stop called . Just you represent same by more doesn't that not to an on of to cognitive , otherwise all programming switches.

My point is, removing "function" and "return" from the syntax, won't necessary easy cognitive load, at least not for senior JavaScript coders. It will save bandwidth though! :P

Yes, but if you write a few thousand of those arrow functions, you will hate the useless function (a) { return b; } stuff, too.

If you're writing a few thousand functions, you're doing something very wrong.

It's like when languages make threads easy to create - and then programmers go away and use threads for everything!

Maybe some verbosity is a good thing because it makes programmers think about whether they really want to do something a few thousand times.

Javascript is a functional language. You _should_ be writing many functions, possibly thousands in a large codebase.

Javascript has first-class functions and anonymous functions, but so do lots of imperative languages, and there are plenty of other reasons to see Javascript as an imperative language. The reason we end up writing many anonymous functions is because we are using interfaces like foo.map(...) instead of interfaces like for-loops which take a block as a body (because Javascript for-loops are unbearably clumsy, e.g. iterating over properties instead of elements).

You find it harder to read because you're not used to it, that's all. Once you absorb the syntax it'll feel more native, and you'll format it in a fashion that makes it easier for you to absorb at a glance.

Here are some fun counter-examples

  let sqr = x => Math.pow(x, 2)

  let property = name => obj => obj[name]

  let distance = p1 => p2 => Math.sqrt(sqr(p2.x - p1.x) + sqr(p2.y - p1.y))

  let byComparing = f => (x, y) => {
    let fx = f(x), fy = f(y)
    fx < fy ? -1 : fx > fy ? 1 : 0
  }
  
  let points = [{x: 1, y: 2}, ...]
  
  let byX = points.slice().sort(byComparing(property('x'))
  
  let byStartDistance = points.slice().sort(byComparing(distance({x: 0, y: 0}))

That's indeed pretty fun. In practice however this is much simpler:

    let sqr = x => Math.pow(x, 2)

    let distance = (p1, p2) => Math.sqrt(sqr(p2.x - p1.x) + sqr(p2.y - p1.y))

    const zero = Object.freeze({x: 0, y: 0})

    let byX = points.slice().sort((p1, p2) => p1.x - p2.x)

    let byStartDistance = points.slice
        .sort((p1, p2) => distance(p1, zero) - distance(p2, zero))

It's not nearly as composable, sure, but I think almost everyone would understand it much faster. The curried `distance` would also be a bit annoying to reuse in other contexts where you'd have to write `distance(p1)(p2)` instead of the idiomatic (at least now; idioms can change) `distance(p1, p2)`.

That said, the arrow function is a massive win in both examples. I've been using it for a while and never had any issue mistaking it with <= or >=. The linter would probably catch it anyway.

The syntax isn't new, and people haven't had issues with it in other languages.

Your parent post skimmed over an important detail, it's not just a new syntax, it's new type of anonymous function with a new type of scope. It's more like:

function(arg) {statement;}.bind(this)

Yeah like the others said it binds this to the scope where it was defined. So something like this works as one would expect:

    setTimeout(() => this.someMethod(), 1000);