arrow-function4-150pxOne of the most famous features of ECMAScript6 is the arrow function.
The arrow function is a shortcut for `function() {}` which can now be written like so `() => {}`. And it embeds a second feature: lexical `this` binding.
I have struggled with it and enjoyed it. Read about why it sucked and where it added value.

The obvious advantages

It was around end of 2014 when I felt I had to pick up on the move forward of JavaScript, I started to dive into ES6. The arrow function was one of the first things I adapted in a lot of places. It is beautiful to write

instead of

way less boilerplate, much nicer to read and more expressive.
As soon as my brain got used to mapping `x => x` or `(x, y) => x + y` to function declarations (with implicit returns) those constructs became meaningful to me. You know how it is, you need to use it a couple of times until it feels familiar and doesn’t require real effort anymore to be useful. It’s just practice.

Replacing all `self` and most `bind()`

You also remember the `self = this` and `this.method.bind(this)` uses that polluted the code? Or the `bind()` at the end of a big anonymous function, which makes it easy to overlook and hard to find out the actual scope of that anonymous function. Yes, you remember too!? Or do you still have this in your code? Now is your chance to get rid of it. Start using ES6! And the time is right, look at the list of babeljs users (babeljs, the quasi-standard ES6 transpiler).

One purpose of the arrow function is to allow us to be more expressive in our code like so:

And those are the cases where the new arrow syntax really shines. The code becomes less cluttered and maintaining (lexical) this-scope is much cleaner and more obvious.

Don’t stop learning here!

Be careful though, having bound a method’s `this` via the arrow function does not allow you to re-bind it. The `=>` is a lexical binding! Take the following mocha/jasmine test suite:

`this.testMe` is `undefined` inside the test case and the test will fail. Using the old-style function, this test will pass.

This test run is green now. The test libraries (mocha here) wants to pass the scope (the `this`) into each `it()` by using `apply` or `call`. Which won’t work in the first case, since the arrow function does bind `this` fix to the lexical scope it is in and that can’t be changed!

Expressivness

After I got over the initial excitement of using ES6, especially the arrow function I realized that I very often use the short syntax `let f = () => {}` instead of `function f() {}`.
It was the hipster syndrom that made me use that all over the place. And it was not a good idea, everywhere. Why? If there is no `this` to bind it’s useless and blurs my intention. Actually the latter is even much more explicit and readable when really defining a normal function. “I define a function.” That’s all I do. And that’s what `function() {}` perfectly states, I think. The assignment (using `let`) and the definition of the function (using `() => {}`) don’t need to be separately spelled out, it’s inherent in the `function` syntax, so let it do it’s job.

Adding some `const`

Still in the early days, but some more ES6 experience later, functional feelings and immutability popping up all around I started to use `const f = () => {}`. This has additional value, but I would still argue the syntax is less expressive than the old style. Ok, there is a positive side-effect using `const`. I can not reassign the variable name `f`. In case of using babel it will already complain that I am trying to change the value of a constant by saying `”f” is read-only`.
In my opinion the `const` syntax is also useless here. It may communicate a purpose: “this is immutable”. Is there really value in this more verbose and less readable syntax? Was overriding a function really ever the problem, so that it becomes necessary to make it immutable? I doubt it. (Maybe it also just needs time for me to oversee this new syntax and see the explicitness in it too.)
Though I would agree there is the functional use case where I would also tend towards using that const style syntax using the arrow functions.

Small one-liner functions that are used in a functional style make nicer reads using the `const` and the arrow function syntax.

Conclusion

Back in the years before 2010, when Alex Russell was still the lead of dojo I remember him stating very often that a short-hand for the `function(){}` syntax would be something he likes to see coming to JS. Finally it is there and it does make things handy and more compact.
But doesn’t it come with a side-effect? A side-effect you have to know and understand to avoid falling into it’s trap. As there are many others in JavaScript, like type-coersion, scope-binding, etc. Now there is one more. Make sure to try it out, play with it and get familiar with it.

So I would like to remind you (and me), stay explicit and (try to) evaluate the new things objectively.