ECMAscript, 6th edition might bring us fat arrow notation – Douglas Crockford on fat arrows

function (x) {
    return x * x;
// becomes
(x) => x * x

Douglas’ post concerns itself mostly with the intricacies of how this is bound to the function objectand what the fat arrow notation might bring, what I see is something completely different.


vim (Photo credit: jwalsh)

Proper lambdas!

That’s right, functions that implicitly return with none of that big ugly function keyword! Hooray.

A bit tricky when you need a named function, but so far this is just an unofficial proposal, I’m sure they’ll figure something out by the time ECMA6 comes anywhere near being a standard (not in 2012).

As I said on hacker news Javascript is a beautiful language, trapped in bad syntax, peppered with poor semantic choices. What is left of a language once you take syntax and semantics out of the picture? Quite a lot.

What else is new

Spurred on by excitement I decided to poke around the wiki for the ongoing specification work of Ecma.

Some of the “tentatively approved” proposals include:

  1. Array comprehensions and generators and iterators – a natural notation for constructing lists from lists, used a lot in python and haskell.
    // mapping
    [ square(x) for (x of [1,2,3,4,5]) ]
    // filtering
    [ x for (x of a) if (x.color === ‘blue’) ]

    This naturally extends into generators, where you can have an object generating values according to a pattern – possibly until infinity. (the example given in the proposal are fibonacci numbers, obviously)

    Iterators are a similar beast – you get to define how an object should be iterated over, which gives us nice abstractions for all sorts of things.

  2. Classes – although using prototypes, functions and instances is enough to do everything classes can do, it isn’t very expressive and too much deep knowledge is required to understand the code.

    A class defines four objects and their properties: a constructor function, a prototype, a new instance, and a private record bound to the new instance. The body of a class is a collection of member definitions.

  3. Block scoped bindings – Javascript used to only be lexically scoped, otherwise known to new programmers as “Aaaaaah everything is global what the hell!?”. With the addition of let, const and block functions there will now also be block scope where you can define things to only exist inside two {}.
  4. Modules!

    What has traditionally been solved using require.js will now work similar to how python does it. You get to define modules and then import them where they are needed. Possibly the most earth shattering addition since dependency management in Javascript has devolved into an extreme sport lately.

    // module
    module math {
        export function sum(x, y) {
            return x + y;
        export var pi = 3.141593;
    // client
    // we can import in script code, not just inside a module
    import {sum, pi} from math;
    alert("2π = " + sum(pi, pi));
  5. Proxies – according to the proposal a Proxy is an object that takes two objects – a target and a handler. Where, if I understand correctly, you call functions on the proxy (trigger them), which execute as traps on the handler object, using the target.

    This looks like a new way of handling events.Similar to what modern MVC frameworks are doing where you have a “view” that takes care of safely executing functions when events are triggered.


A lot more interesting stuff can be found in the strawman section where completely far out ideas live, but the tentatively approved ideas already raise my hopes far too much without any assurance I’ll ever get any of this. So much could change before any of this is solidifies into a standard.

And even when it does become a standard … how long before any of this reaches wide browser support? Mozilla’s Javascript already includes a lot of this stuff – a lot of the proposals come from there actually – anyone else? Not really.

At least there is some comfort in the fact all of this will quickly reach node.js 🙂

Enhanced by Zemanta

You should follow me on twitter, here.

Get 10 of my best articles and talks

Leave your email and over the next few weeks I will send you the best material I've written since 2010.

  • Sairiost

    This is as exciting as doing the dishes. “Fat arrows”? Please first let’s just stop inventing stupid names for things that have been around for *decades*. Also, it’s just a trivial syntactic improvement. Bikeshedding anyone?
    Also the introduction of classes will destroy the language.
    The only real improvement here is the long due scope fixing. It’s very embarrassing that in 2012 the most prevalent programming language in the world still has broken scopes.

  • Do you mean that JavaScript used to be only dynamically scoped?

  • Syntactic sugar or not, a lot of languages do very well by being little more than syntactic sugar.

    Classes aren’t so much an introduction (from what I could understand) as they are syntactic sugar for what already exists.

    Really the most interesting thing for me were the modules and the array comprehension things, I have missed both those features on many occasions.

    As for scoping, it isn’t really broken, it just works in a way that’s closer to how functional languages work … in fact it’s not broken at all, most people are just using it wrong. I for one hope block scoping will just make this more readable instead of replacing it fully.

  • No, it’s lexically scoped; from wikipedia (

    With lexical scope, a name always refers to its (more or less) local lexical environment.

    With dynamic scope, each identifier has a global stack of bindings.

  • oh no! this is terrible yet even more ways to do OOP. Why ? Why cant we as a tech community for once keep a language clean and sane.  Why does every language on this planet have to turn into a kitchen sink? Why can’t we make something like C, or objective-C or maybe Python. Now there are zillion ways to do OOP: classes,object.create,__proto__,prototypes,new,functional,parasitic inheritance,builders,literals,augmentations, and some fancy frameworks that have yet another OOP dialect…

  • Python is the epitome of “everything and the kitchen sink” 🙂

    And I don’t really think there are that many OOP flavors out there, it’s all the same crap to me, just bound up in different idiomatic styles.