The Exciting Future of Javascript

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 object and 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 .

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.

when?

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