

EcmaScript Sixth Edition - joeyespo
http://espadrine.github.io/New-In-A-Spec/es6/

======
TazeTSchnitzel
> 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.

~~~
ptx
> 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?

~~~
TazeTSchnitzel
>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.

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

------
VeejayRampay
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?

~~~
laughinghan

        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_...](https://developer.mozilla.org/en-
US/docs/Web/JavaScript/New_in_JavaScript/1.7)

~~~
VeejayRampay
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.

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

~~~
SimeVidas

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

------
adrusi
> 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 :)

~~~
espadrine
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...](https://speakerdeck.com/dherman/a-better-future-for-
comprehensions)

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

------
yoanizer
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?

~~~
VeejayRampay
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.

~~~
yoanizer
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.

~~~
VeejayRampay
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.

~~~
pjmlp
I rather have money on my pocket than angry customers.

~~~
kybernetikos
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.

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

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

------
lukasm
Great summary. Any breaking changes?

~~~
jarek-foksa
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.

------
snorkel
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.

~~~
igl
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

~~~
gsnedders
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.

~~~
BugBrother
>> 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? :-(

~~~
espadrine
> _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.

~~~
BugBrother
>> Why is that?

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

