EcmaScript Sixth Edition | Hacker News Reader

EcmaScript Sixth Edition

espadrine.github.io

40 pointsjoeyespo49 comments

> fat arrow: (a) => a * a is the same as function(a) { return a * a; }

No, it's equivalent to the following:

  (function (a) { return a * a; }).bind(this);

The fat arrow has lexically scoped this.

On an entirely different note, I never liked how generators are marked with an asterisk. A generator isn't special, it is just a function returning an iterator. A generator should be able to return normally as well as yield.

You're absolutely right! Fixed, thanks!

(PS, repository is here: https://github.com/espadrine/New-In-A-Spec)

Generators have to be marked as an asterisk as otherwise there's ambiguity; until recently 'yield' wasn't a reserved word, so it might be a variable name or anything. Without disambiguating (via the *) old JavaScript can potentially break.

'yield' was a reserved word in the ES4 spec, and a 'FutureReservedWord' in ES5 so if there is code that uses it as an identifier, it has been technically broken since 2008...

What ES4 says is irrelevant. yield is only a FutureReservedWord in ES5 when within strict mode code; in non-strict code it is not a keyword, and plenty of code uses it and works in ES5 implementations.

> A generator isn't special, it is just a function returning an iterator. A generator should be able to return normally as well as yield.

But in a generator function the iterator is returned immediately, before any of the code in the function runs, so how would it return anything else?

For example:

  function* f() {
      console.log("function commencing!");
      for (x of [1, 2, 3]) {
         console.log("yielding " + x);
         yield x;
      }
  }

  var it = f();
  console.log("iterator returned from function:", it);
  console.log(it.next().value);

would print:

  "iterator returned from function:" Generator {  } Scratchpad/1:19
  "function commencing!" Scratchpad/1:11
  "yielding 1" Scratchpad/1:13
  1

So even if the very first thing the function does is

   if (isTuesday())
     return something;
   else
     yield somethingElse;

...by that point it would have already returned an iterator, so it would be too late to decide otherwise, wouldn't it?

>But in a generator function the iterator is returned immediately, before any of the code in the function runs, so how would it return anything else?

Oh, that's interesting, I didn't know ES6 implemented generators that way. That's really weird.

EDIT: Looks like PHP does the same thing. Hmm, I can see the merits of an asterisk, then.

Python works the same way, so I just assumed ES6 did as well and tested it in Firefox. :)

All those additions are welcome (and wayyyyyyyyy overdue to be honest) but something is striking me as quite old-fashioned :

  for (var [key, val] of items(x)) { alert(key + ',' + val); }

That syntax isn't really natural, I would think something like:

  items(x).forEach(function(key, value) {
    alert(key + ',' + val);
  });

is more natural and readable. It also brings up the question of interpolation, why do we even have to use + in the first place?

Also, can someone in the know care to tell me why that is that those additions for what is the end rather basic functionality is coming so late to the language?

>Also, can someone in the know care to tell me why that is that those additions for what is the end rather basic functionality is coming so late to the language?

I would think Internet Explorer being the dominant browser had something to do with it.

Iterables can have many forms (Strings, Arrays, Maps…), so having a forEach method is tricky.

On the other hand, most iterables have their own methods to loop around values. Arrays and Maps both have a .forEach() method.

    items(x).forEach(function(key, value) {
      alert(key + ',' + val);
    });

You can already just do that, without ES6.

> It also brings up the question of interpolation, why do we even have to use + in the first place?

Did you miss the last item, "quasis"? `You are ${age} years old.`

> Also, can someone in the know care to tell me why that is that those additions for what is the end rather basic functionality is coming so late to the language?

Because unlike most languages, there's no canonical implementation.

Mozilla, who actually holds the trademark on the name "JavaScript", totally tried to evolve the language since the beginning and even shipped e.g. JavaScript 1.7 (which had generators, iterators, let, array comprehensions, and destructuring assignment [1]) with Firefox 2 in 2006, but Firefox just didn't have the market share for authors to start using the new features, and no other browser implemented any of them. That deadlock was only broken by Brendan Eich using corporate politics rather than hacker-style "putting it out there": rounding up all the big browser makers (of course, it helped that Apple and Google had just broken into the scene), and convincing them to commit to implementing new features decided on by the committee they formed, TC39 (and to update their browsers at all, ahem IE ahem).

[1]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/New_...

Unless I'm missing something, you cannot use forEach on a Javascript object as of now (or map, reduce, every, some and other methods that are available on Array.prototype).

The only way is to use:

  for(var key in obj) {...}

As for interpolation, I indeed missed the bit about quasis. Though I really wonder why they would still use concatenation if they can interpolate... Maybe to only show one feature at a time, which I guess makes sense.

You are correct, there is no forEach, a lot of libraries implement their own, but no native version.

    Object.keys(obj).forEach(function (key) {
        var val = obj[key];
        
        // use key and val here
    });

I think you did miss something: the comment you replied to didn't say

    x.forEach(f);

but rather

    items(x).forEach(x);

which is definitely possible, you just need to implement items().

Sun/Oracle has always held the trademark on JavaScript, not Mozilla. And TC39 predates the "JavaScript Renaissance" that you're talking about.

"JavaScript is a trademark or registered trademark of Sun Microsystems, Inc. [...] used under license."

https://www.mozilla.org/en-US/foundation/trademarks/list/

TIL!

And you're right about TC39, I probably should have said "joined", not "formed", if I could edit my comment I would.

I don't think my comment was a gross misrepresentation of the historical context, though.

> Also, can someone in the know care to tell me why that is that those additions for what is the end rather basic functionality is coming so late to the language?

Back when IE was stagnating, when nobody was working on anything more than maintaining IE6, TC-39 (the technical committee that works on ECMAScript) was working towards a 4th revision of the standard (i.e., ES4), incorporating a lot of quite reasonable things (like the above) but also quite a lot of things based on very recent research. There was pushback against quite so aggressively moving forward in a single revision, especially incorporating so much from academia not already proven elsewhere (the browser space is very conservative about breaking existing content, so if something that turned out to be a bad idea shipped, it'd be very very hard to get rid of). In the end, there was relatively significant pushback once MS reappeared from themselves, Yahoo, and a number of other contributors.

Moving forward, the plan was essentially to tidy up the ES3 spec with minor additions, which was originally referred to as ES3.1 but eventually standardised as ES5. ES6 is the next revision of this branch of the standard.

ActionScript 3, as Flash uses, is based on one of the drafts of ES4, and prior to the abandonment of Flash development, the intention was to continue to evolve the language separately to ECMAScript.

> array and generator comprehension: [a+b for (a in A) for (b in B)] (array comprehension), (x for (x of generateValues()) if (x.color === 'blue')) (generator expression).

Bit of an error here. The array comprehension uses "in" which will iterate over the indexes of A and B. While this is technically valid, no one would look at that and expect it to return the string concatenation of all the indexes of A and B :)

You're right; I didn't update the example while the syntax was in flux. Fixed! ☺

(There's no certainty that the syntax will be kept, though, see this[1] about deferring it to ES7 to generalize the syntax for parallelism, and this[2] to make async promises and generators work together.)

[1]: https://speakerdeck.com/dherman/a-better-future-for-comprehe...

[2]: https://docs.google.com/file/d/0B4PVbLpUIdzoMDR5dWstRllXblU/...

Ok but when can we expect to start using that and have our web apps work in the real world? in 10 years? 20 years?

~10 years.

Much faster if you are willing to punish your users for using subpar browsers that don't keep up with current technologies and standards.

A bullet I retrospectively think we should have bit a long time ago. It would have sent a strong message that you either make sure that your browser is top notch or it will be left behind to bite the dust of the power horses.

Now that Microsoft is feeling the heat under its ass (from FF, Chrome and Safari), they're making sure IE is not ridiculously worse than the competition, that it auto-updates, they're engaging the community, creating libraries, etc.

I can't even think about blaming my Clients for not using the latest IE because I want to use some syntax sugar for things that I can already do with ECMA 5.

That's not what I'm saying. I'm talking about 5 years ago when IE7/IE8 were lagging behind by a HUGE margin and it was another world trying to make things compatible. It was not a matter of using the last version, it was a matter of Microsoft not paying attention or not wanting to make its flagship browser better. Not just some developer throwing a fit because he needed "sugar".

Also, and that's only personal opinion, but there's a limit to the customer is always right. What if we create a new super highway one day with flying cars, are we going to punt on moving on because some people like their combustion engine pieces of junk? It's also our jobs to make people understand that jumping on the latest technology is in their best interest. Leveling the field to the lowest common denominator brings everyone down in the end and really hampers creation and innovation.

And that is the reason why Javascript is so far behind modern languages in so many areas.

I rather have money on my pocket than angry customers.

What you seem to be missing is that having to develop for old browsers also costs money.

At some point, it's no longer worth the business of the small number of e.g. IE6 users to put the extra effort in creating a site that can work in it.

You are missing the amount of zeros before the comma (or decimal point).

>Much faster if you are willing to punish your users for using subpar browsers that don't keep up with current technologies and standards.

Actually Chrome is a complete mess ES6 compatibility wise.

Most of the interesting stuff is unimplemented still, and what is there is hidden in options the user has to specifically enable.

Sure, the standard is (now) only due for 2015, but Chrome dragging its feet is also one of the reasons for that. And it's not like FF waited for the standard to be stamped and released to have the implementations according to the standard already working.

Today https://github.com/google/traceur-compiler

That's not using those features. That's using a bizarro extra step to the workflow to get a non native implementation.

traceur-compiler can preserve ES6 syntax (without desugaring it), it's only missing automated feature detection at runtime (which I wanted to add more than an year ago, but was busy with other things).

Some of it can be used today in TypeScript.

Nearly everything works in firefox. Most features exist in Chrome but are marked experimental and can be enabled by a command line flag (I think). If you're selling a continuous integration service to developers, you'll probably be perfectly fine using any of this in a year or two. If you're selling "how to use your email client" video lectures to the elderly, you might have to wait 10 years. There is no single "real world".

Awesome! Most of these things works under Firefox if you want to play.

Great summary. Any breaking changes?

No.

In ES6 "typeof null" will give you "null" rather than "object". There were also some talks on making "__proto__" non-mutable, but I'm not sure whether this breaking change made it into the spec.

Please stop evolving Ecmascript. If this continues then soon JavaScript will have gone from a nice simple, elegant language into C++ 11, incomprehensible to both humans and machines, and then the replacement languages will start to proliferate, fragmentation, ugh ... Let's just agree that JavaScript only needs minor enhancements, not mind bending magical operators and keywords. Please don't do to JavaScript what perl6 did to perl. If you want a mind numbing language then please use Haskell or erlang, and let JavaScript remain simple.

I completely agree. It's like they did not learn from javascripts mistakes and just continue doing them.

Global Scope: not fixed. No integer: not fixed. Syntax to resemble JAVA more closely in a class-less language that already as 9999999999999 class libraries: FIXED

How can you fix the global scope without breaking almost all existing JS code? Browsers will never ship anything that breaks large numbers of existing websites (users don't use browsers that don't work with the web!).

Adding an integer type is far easier said than done. It was decided to leave that hard problem to ES7; integer type (or types!) are certainly coming.

>> How can you fix [X] without breaking almost all existing [Y] code?

For most cases of X, some form of declaration that is scope bound.

Look at e.g. Perl, it changes quickly in this way, with very good backwards compatibility. [Also see strict mode, of course.]

Edit: That said, new keywords like those let/const/module/extends etc should work fine. Please give me them today.

Edit 2: I have been cursing the lack of multiple returns this week. It is a pain returning a hash/object or an array. That really isn't supported, from browsing the standard? :-(

> Edit 2: I have been cursing the lack of multiple returns this week. It is a pain returning a hash/object or an array.

Why is that?

  let rational = (a, b) => [a, b];
  let [numerator, denominator] = rational(38, 4);
  let reduced = rational(numerator/2, denominator/2);

PS. The above code works in stable Firefox.

>> Why is that?

<Cough> Obviously because I'm blind? :-) Thanks.

There's an unwillingness to introduce too many opt-ins into JS as it quickly leads to ever increasing implementation complexity. Note that Perl is one of the few notable languages to have such sort of opt-ins.

* All modules are automatically in strict mode, so global scope: fixed?

* `new StructType({x:uint32, y:uint32, color:Color})` - looks like integers to me..?

I didn't add TypedArray because technically that was first spec'ed by Khronos for WebGL, but you already have integers in every modern browser right now, and it will be in ES6 as well!

> Please stop evolving Ecmascript.

A language that doesnt evolve is a dead one.

> JavaScript will have gone from a nice simple, elegant language

It's neither nice,nor simple nor elegant.To many WTF,to many edge cases,and a verbose syntax.

The code you are writing today will still run with ES6.

Nobody is forcing you to use new features.

You may like ES5,you may like how one writes ES5 code.That's not my case and the case of many developpers using javascript everyday. These features, we should have had then back in 2007 with ES4.So this isnt even an evolution,this is a catch up.

> C++ 11, incomprehensible to both humans and machines

I prefer devs using the same "incomprehensible" language than having to use 10+ transpilers because devs dont get what they want with javascript.

Again,nobody's forcing you to use ES6 new features,so you shouldnt force people into what you deem "nice,simple and elegant". Devs are forced to use JS one way or another,so let's make it so all devs can at least work with it instead of trying to force everyone into a paradigm everybody is not going to agree with.

And the best is yet to come with structs,guarded types,async/await keywords,more data structures,...

Reply on news.ycombinator.com