
ES6, ES7, and beyond - gsathya_hn
http://v8project.blogspot.com/2016/04/es6-es7-and-beyond.html
======
dherman
(TC39 and Mozilla member here.)

FWIW, this:

    
    
        For these reasons, the V8 team, along with TC39 committee members from Mozilla and Microsoft, strongly support denoting proper tail calls by special syntax.
    

is misrepresentative of the state of consensus and frankly premature. In
particular, while I won't try to speak for all of my colleagues (we do not
pre-determine an official Mozilla position in advance of standards discussion)
I don't _think_ it's the case that any of the Mozilla representatives
"strongly support" syntactic tail calls, and I personally have reservations.
It hasn't gotten beyond being an area of open exploration.

All that said, I'm interested to see where the explorations go, and I'm
looking forward to subsequent discussions.

~~~
coroutines
I would really be interested to know why we need a special syntax for tail
calls. (genuinely curious)

I'm from Lua originally and we've had tail calls forever... why would you
point them out? It should be obvious:

return wat()

~~~
LewisJEllis
I'm not on TC39, but I sit next to and work closely with people who are, and
my understanding (confirmed by this article) is that the primary concern is
about stack traces of existing code, specifically code with function calls in
tail position.

With implicit tail call elimination, those stack traces will change in non-
trivial ways that could affect debugging processes or break existing tools.

I've also heard some concerns about implementation difficulties, but I know at
least one major engine has implemented PTC as specified in ES2015 without
issue. I think (and hope) these concerns are secondary to the discussion about
stack traces and backwards compatibility.

tl;dr: as with almost every "why is it like that" question about JavaScript,
the answer is "because backwards compatibility".

(I also started with Lua and have adjusted to JS over the years; they have
more in common than many people realize!)

~~~
yoklov
I'm not particularly in the loop on this, though I have talked about it
(idley) with a member of TC39, but my understanding is that implementation
difficulties are a big part of it. SpiderMonkey and Edge both are having
difficulties implementing it without hurting the performance of average code.

------
spdionis
> String.prototype.padStart() / String.prototype.padEnd()

Finally left-pad module's functionality will be integrated into core! Souns
awesome. /s

~~~
deadowl
I would really like if Unicode properties were implemented. I'd also like to
see a RegExp escape function. String padding sees common enough usage that it
should be added.

~~~
hashseed
Unicode properties are behind an experimental flag: --harmony-regexp-property

~~~
deadowl
Good to know!

------
grayrest
So in looking at the Kangax tables when the next Safari comes out, it looks
like all major desktop browsers will have support of the big ticket ES6
features (arrow functions, destructuring, default params, Map/Set/WeakMap,
Proxies). Unless you're doing JSX, type annotations, or upcoming stuff
(async/await, decorators, object spread, class properties) you can drop
transpiling from your dev workflow and only do it for prod.

~~~
jay_kyburz
I thought IE11 and earlier have none of these features right? And you can't
run Edge on windows 7 right? And aren't more than 50% of windows sill Windows
7? And in't windows still 90% of the market?

I was thinking these features are still 5+ years away unless you are prepared
to actually ask your users to switch to Chrome.

~~~
callahad
Transformation of most ES6 features into functionally identical, backwards-
compatible ES5 is trivial, and automated tools exist to do that, so you
absolutely _can_ use them today.

For example, default arguments are purely syntactic sugar for `if (arg ===
undefined) { arg = x; }` in the first line of a function. Still, I'd much
rather _write_ ES6's declarative `function foo(arg=x) { }` syntax rather than
imperatively implement it in ES5 each time I need it.

~~~
zeckalpha
> I need it.

Need is a strong word.

~~~
callahad
In this case, "need" refers to the "if (x === undefined) { x = y }" pattern.
Which is absolutely a need when implementing functions with variable arity.

If I need that pattern, I'd rather write it declaratively than imperatively.
:)

~~~
zeckalpha
Variable arity is exactly the thing to which I refer. It isn't needed.

------
grifter2000
PLEASE don't do the awkward .mjs thing. I and prob most devs will simply not
respect it.

~~~
pornel
.es sounds good to me.

Seems like a good fit for _EcmaScript_. It might even help finally renaming
the language, so that tech recruiters confuse it with something else ;)

~~~
inglor
That would be incorrect though, there are other implementations of the ES
specification that are not JavaScript (UnityScript for example).

Although it's a cute suggestion.

~~~
greggman
WAT? UnityScript is not an implementation of ES AFAICT. It's entirely made up
by Unity and has almost nothing in common with JavaScript/EMCAScript

------
faide
> [http://tc39.github.io/proposal-string-pad-start-
> end/](http://tc39.github.io/proposal-string-pad-start-end/)

Not to beat a dead horse, but I find it hilarious that this is a proposal.
Someone on TC39 has a sense of humor.

Edit: Apparently this was proposed long before left-pad broke the internet.

~~~
calebegg
Not to be a wet blanket, but this proposal predates padLeftGate by a lot:

[https://github.com/tc39/proposal-string-pad-start-
end/commit...](https://github.com/tc39/proposal-string-pad-start-
end/commit/5e370dc4731aa12c88def15a0b2acc78952c9677)

[http://wiki.ecmascript.org/doku.php?do=revisions&id=strawman...](http://wiki.ecmascript.org/doku.php?do=revisions&id=strawman%3Astring_padding)

~~~
faide
Good catch, I stand corrected.

~~~
dherman
Still, I wouldn't say _nobody_ cracked a smile at the last TC39 meeting... ;P

------
raarts
Is there already a proposal for (optional) type safety? So we can assimilate
the typescript fans?

------
lucasmullens
What happened to the year-based naming convention? I thought we switched to
ES2015 and ES2016?

~~~
have_faith
I still don't understand why it's been renamed to ES2015. Reminds me of the
Windows98 days. Gives software an air of "out-of-date"-ness for no reason.
Just give it a version number and be done. Javascript versions don't need
branding.

~~~
WorldMaker
I'd think there are plenty of reasons to give software an air of "out-of-
date"-ness. In this particular example, its a stigma to browser developers if
it takes them until 2023 to implement ES2015.

It's a common thing in language standards to version by the year the standard
was ratified, especially for ANSI languages such as C and C++, but there's a
long history of it in language design including the ur-example off the top of
my head of ALGOL68.

As for Windows 98. Would you seriously with a straight face want to admit to
using a version of Windows that is old enough to vote? If anything, it's too
bad they stopped that pattern with XP as it would have been a lot easier to
shame people for still using Windows 2001 in 2015.

~~~
Buttons840
MySQL still hasn't implemented "with statements" and I miss them frequently
when working with MySQL. The fact that "with statements" were added to the SQL
standard in 1999 doesn't seem to bother anybody though, and MySQL continues to
gain popularity.

~~~
WorldMaker
I've been Team PostgreSQL for a long time in the FLOSS DB Wars, so take this
with a grain of salt, but that MySQL hasn't managed to implement "ancient"
standards certainly has bothered me over the years and there are certainly
plenty of other people on Team PostgreSQL that have been pointing this stuff
out for in some cases decades. So yes, shame on MySQL for failing SQL99 (and
heck, shame on them for failing SQL86 in their basic [lack of] ACID compliance
in their default DB storage for far too many years).

So yes, this certainly feeds my point that standards years can be useful to
point out the quirky failings of software by potentially adding to their
shame. It's 2016, are you using an SQL-1986-compliant database?

------
apo
>Although additional standardization work is needed to specify advanced
dynamic module-loading APIs, Chromium support for module script tags is
already in development.

Of all the future developments in V8, this is what I'm looking forward to the
most. It's the last key component tying most code to transpilers.

------
eknkc
Seems that there's no mention of async functions and no browser support apart
from Edge. Are there any concerns about it's availability in ES7 at this
point?

~~~
calebegg
ES7/ES2016 does not/will not include async functions. It will likely make it
into ES8/ES2017, though.

[http://www.2ality.com/2016/01/ecmascript-2016.html](http://www.2ality.com/2016/01/ecmascript-2016.html)

~~~
SomeCallMeTim
THAT is truly disappointing. Of all the new features, async/await is possibly
the most critical for improving readability of code.

It's even more of a step forward than Promises was.

~~~
snuxoll
It's not really that big of an issue for it to still be in the standards
track, async/await can be emulated using ES6 generators - in fact, if you
target ES6 with the TypeScript compiler it will just implement a generator for
you to handle the async stuff. I'm not certain if babel or any of the other
transpilers do it yet, but it's not that much of a challenge.

Of course, it will be nice to not need transpilers and I know a lot of people
were hoping ES7 might be the end of it - but I don't see it happening anytime
soon. Hopefully, though, more standards will be amenable to shims like this,
so at least we can get them _now_ while waiting on browser support. (That
said, I hate web apps, this stuff drives me mad. I'll stick with GTK and WPF).

~~~
SomeCallMeTim
I've been using the Babel transpiler to get async/await, and the code is _so_
nice. Showed it to a JavaScript-hater and he gushed over it for 10 minutes --
then repeated the same comments to his boss (my client), which was awesome. :)

But I'm hearing that both the Babel and TypeScript implementations leave a lot
to be desired with performance. Not so bad that it gave my use case a problem,
but I use NodeJS, in part, for performance.

I'm also targeting browsers (and hybrid apps) with some code, and I've
recently jumped from Babel/ES6 to TypeScript, so I can get the support via
generators, but again I'm hearing of performance issues.

Getting first class optimized browser support is where I'll feel it's truly
awesome.

------
hajile
The two reasons for tail calls are loops and CPS. Nobody is championing the
idea that we need traces for each loop iteration. I would somewhat understand
the CPS argument except that the event loop already destroys a huge amount of
meaningful stack traces anyway (while not identical, it is somewhat similar).
I don't see anyone insisting on stack traces there either.

Why do we need explicit tail calls with stack traces?

~~~
nostrademons
That's an argument in favor of explicit tail call syntax. If there are only
two main use-cases (loops and CPS), then why not annotate those two use-cases
and leave everything else untouched?

The problem with implicit tail call syntax is that suddenly stack traces will
be elided from debugging info when you really just wanted a normal function
call that happened to be in tail position. These are really hard-to-track-down
bugs, since the stack frame that is elided is precisely the one that made the
tail call.

------
_mikz
Unreadable in mobile safari. Way to go.

~~~
s3th
The gutters are a little small on my iPhone, but I can see all the text. Want
to send a screenshot to seththompson [at] google [dot] com? I'll see how much
I can fix.

