ECMAScript Harmony’s arrow functions

05 Jun

After being out of the loop for quite a while for personal reasons, I got around to getting myself back up to date. One thing I’ve been playing around with is Spidermonkey’s implementation of new ECMAScript features introduced in the 6th edition draft specification.

When I first read the proposals for arrow functions a couple of years ago, I was put off quite a lot by the syntax and I just thought of it as something impure that CoffeeScript developers were trying to force into the language. Maybe I’m a little more open-minded now because, after actually getting to use them, my mind has changed completely. I think the new syntax is beautifully concise, and the real issues that arrow functions solve make it more than worth the short amount of time you’ll need to get acquainted with them. Take the following example:

    // Numerical sort, the old way
    someArray.sort(function (a, b) { return a - b });

    // The new way
    someArray.sort((a, b) => a - b);

It’s not just about saving bytes, though. Arrow functions offer an extra conveniences: no prototype property, internal [[Construct]] method, and lexical this. This means that an error is thrown if they are used with the new operator, and the value of this is fixed to whatever it is in the parent scope:

    // This will cause an error
    new (() => {});

    // `this` inside the timeout function is myObj
    var myObj = {
        myFunction: function () {
            setTimeout(() => alert(this.myProperty), 500);
        myProperty: 'Hello!'

    // alert: 'Hello'

That’s really great, and I’m impressed that we’ll be able to ditch Function.prototype.bind() for cases like these. But what if we wanted dynamic this? There have been some proposals, such as thin arrow syntax, but some feel that the proposals add would add confusion with casual coders or that dynamic this isn’t important. On Kevin Smith’s survey of 20667 functions from a large number of code bases, Dr Axel Rauschmayer wrote the following:

These findings mean that JavaScript most urgently needs easy ways to define subroutines (with lexical this) and methods. therefore makes the right choices. Another implication is that arrow functions with dynamic this are not that important, even for current JavaScript code.

The confusion argument holds a lot of weight, I suppose. Like the difference between single quotes and double quotes in Perl/PHP/sh/etc, having fat arrows and thin arrows in JavaScript could cause the same confusion. However, in my experience, such confusion is usually cleared up in a very short period of time. We should be trying to improve the language for people who use JavaScript every day, rather than people who just write a couple of functions every 6 months to 2 years.

That being said, if there’s no call for it, then maybe it shouldn’t exist. I did think of one (albeit small) use case recently where dynamic this in arrow functions would shine: generic instance methods. You’d always want these to be lightweight (no [[Construct]] or prototype) and dynamic this. Take shims of native array generics introduced in ES5, for instance. You’d never get these to pass their respective tests on the test262 suite because all the existing shims have a prototype property and don’t throw an error when you try and construct them. With dynamic this, we could make ES6 shims of ES7 functions virtually indistinguishable ― Function.prototype.toString aside ― from their native counterparts and use the test262 suite to verify them. Like I said, it’s a small use case, but I think it would be nice to have.

Either way, I’m looking forward to being able to use arrow functions in JavaScript. As soon as the finalised specification draws near, I think we can expect minifiers to adopt support for this syntax and churn out backwards-compatible minified code.


Leave a Reply


  1. Dew Drop – June 6, 2013 (#1,562) | Alvin Ashcraft's Morning Dew

    June 6th, 2013 at 11:48 am

    [...] ECMAScript Harmony’s arrow functions (Andy E.) [...]