ES6 is JS2

2013-03-25

ECMA is the organization that's, amongst others, responsible for the ECMAScript specification, which in turn is the foundation for JavaScript. We short that to JS to get rid of the bullshit capitalization arguments (because the official trademark is for "JavaScript"). And because it's shorter :)

13-02-02: Updated to correct a few errors.

Okay so there have been four versions of ECMAScript, and one version that was discarded (ES4). Upcoming is ES6, which introduces some drastic thoug h long awaited features. While it seems everybody is divided on whether they like the whole of it, there's bound to be something in it for everybody. And regardless of how "the people" feel, ES6 is going to happen, barring another ES4 filibuster. And I'm not so sure whether that's going to happen again. The stakes are much higher this time and there doesn't appear to be too much opposition in the TC39 right now.

I've stopped following es-discuss too closely and now only read the initial emails of a topic, unless there's a good reason for it to continue following the thread, they tend to get polluted quite fast and I stop caring. This does mean that I've missed out on quite a bit of language changes that have been proposed and even seem ready for release. When I read some of the random examples you can find on es-discuss, I feel like I'll have to learn a new language.

Juriy said it right. Can you decipher what this might mean?

Code:
{ [foo](bar) { } }

I sure as hell can't right off the bat. I don't even know whether he's added the outer curly braces as a form of (MD) backtick. Even knowing about the variety of weird destructuring forms, I still don't know what this should mean. The terms "method definition" and "computed property" don't mean anything to me (in the context of JS and this example), nor do their English meaning help me to decipher that snippet of code.


Okay, so it seems this is invalid syntax, though Rick's response and examples confuse me and I'm not sure what it should have been.

There are many more gems like that. I'm looking at some slides by Axel of an upcoming talk. Try destructuring:

Code:
let { first: f, last: l } = {first:'Jane', last:'Doe'};
let { first, last } = { first: 'Jane', last: 'Doe' };
[x,y] = [y,x];

Ignoring the let, the first two shows you how you can easily assign object property values to variables. The second does the same, but for arrays. They are reasonable, although allow for very hard to read code when combined with other features.

Fat arrow, or lexically scoped functions:

Code:
friends.forEach(friend => { ... })

Though I like a simpler way to define lexically scoped functions (they prevent me from having to .bind(this) event handlers, and such), I'm not sure yet about the fat arrow. Especially with some of it's restrictions, the fact that it's only available in "strict mode" (last I heard) and its implicit return value... well, time will tell on this one. The arrow itself will also add to the "grawlix" noise. There's an example later that illustrates this dangerously close:

Fat arrow is not restricted to strict mode
Implicit return value: My objection is that it's harder to read what the code is actually doing. An explicit return keyword helps greatly in this.

Code:
let squares = [1, 2, 3].map(x => x * x);

Yes, this looks fine in this concocted example, but will it still in actual code? I wonder...

Rest parameters are actually not so bad:

Code:
function foo(a,b,...c){} // c is an array

Put any arguments beyond the second into that array. Will replace arguments in due time, if not sooner. But functions also allow destructuring their parameters...

Code:
function func3(arg0, { opt1 = 3, opt2 = 5 }) {}

This is new to me, actually. Looks a bit wonky.

The rest parameter (the three dots) are also used as a spread parameter, which applies the contents of an array to a function call as individual parameters (much like apply does).

Code:
var b=[1,2];
foo(a, ...b);
// would be same as
foo(a,b[0],b[1]);

Okay...


The slides mention something about Symbols. That's actually completely new to me. The example seems super confusing though :(

Code:
[sym](arg)

I read this as if you're calling an array literal. Which is illegal in JS (I'm sure this is the rationale for allowing this syntax in the first place, but it still looks very bad to me).


Nevermind about Symbols, they are simply "guaranteed unique property keys". Example snippet

And then we have comprehensions. I think they are from lisp? Or maybe python, I don't know...

Code:
let squares = [for (x of numbers) x*x];

I do know that while this example looks fairly reasonable, I've also seen examples which are a complete mindfuck to parse.

Other additions to the language, at least discussed in those slides, are not burdened with new syntax. So let's try to combine an example of the above features...

Code:
function meh(a,b,{c="hello", d="world"}, [e,f], g, ...h){
console.log(a,b,c,d,e,f,g,h);
for (num of (for (x of (for (x of [1,2,3]) x)) x*x)) console.log(num);
}
meh(...[1,2,3,4,5,6,7,8,9],[10,11,12]);

Can you figure out the output? I don't even want to bother. And yes, I know this is an artificial example, but do keep in mind that so are all the others that have been posted to es-discuss so far. And while they are fairly legible on their own, they will quickly turn into a weed that destroys all hope of generating readable code. Has this been a problem for python? No. Is this python? No.

This example doesn't even contain anything that breaks the flow ("yield"), or for example the templating engine ("quasi-literals") which also have lots of fancy code changing effects.

So back to my point. While the previous versions of ES were _mostly_ backwards compatible, especially in the syntax department (yes, reserved identifiers as keywords. yes, trailing and elided commas), they also kept the main gist of the language the same. The biggest change there are getters and setters and I still don't agree to them. But all in all, the language remained to be JS. And anyone reading ES3 would have virtually no problem reading ES5. As far as I know, this was true for the transitions to ES2 and ES3 as well.

It will not be for ES6. There are so many new syntax introductions. So many new feature additions (proxies, sets, maps, modules, iterators, ...rest) that I think we should start calling it JS2. Because really, that's what it is. It's the next main version of our beloved language. And for better or worse, there are some drastic changes in there that are on a different level from the previous version transitions.

I know I've been fighting some of these changes for a while and I have not changed my mind. While they allow for new things to do, they're making JS less like JS. And I can't help but not like that... :/

So, ES6 is JS2. Huzzah, huzzah, huzzah...


Okay. There were quite a few changes between ES2 and ES3... Looking at the list Rick mentioned it's hard for me to say whether I would have felt the same way then. So maybe my comparison to earlier days are wrong. And maybe earlier changes to the spec had about as much influence to what it means to be "JavaScripty" as the upcoming changes are going to it next. And maybe I'll look back at this a few months after its release and laugh at myself. And maybe I won't.

While many of the changes are going to allow the coder to write shortcuts for one thing or another, many of the syntax changes would mostly promote writing code that's hard to read or hard to follow. I really hope they get labelled "use with care" somewhere, when it turns out that's the case. </grumpy mode>