ES6, ES7, and beyond

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

[LittleDan]

Sorry for the inaccurate shorthand; maybe that should read that SpiderMonkey supports it. Eric Faust of SpiderMonkey is a co-champion of the proposal, and spoke against implicit PTC at the March 2016 TC39 meeting. It's hard to get much stronger in support of a proposal than being a champion, and Eric works for Mozilla. From that discussion, it also sounded like there was support from the Mozilla devtools team as well.

I'm interested in getting everyone's point of view. We've been discussing pros and cons at https://github.com/tc39/proposal-ptc-syntax/issues and https://github.com/tc39/ecma262/issues/535 , and it'd be great to have your input, including the overturning-prior-consensus issues you raised in committee and anything else that comes to mind.

EDIT: How do you like the new wording "For these reasons, the V8 team strongly support denoting proper tail calls by special syntax. There is a pending TC39 proposal called syntactic tail calls to specify this behavior, co-championed by committee members from Mozilla and Microsoft." ?

[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()

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

[seniorsassycat]

the whole reason left pad was such a big deal is because of padStart.

People writing polyfil's to add padStart to String.prototype used left-pad.

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

[zghst]

Well, not completely, other devs who are working on the same project might not enjoy debugging why X isn't working on a certain browser.

[grifter2000]

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

[stupidcar]

That's up to the Node.js team, not the V8 team, right?

But yes, Node.js team, please don't inflict .mjs on us, or let your extreme NIH block the introduction of ES2015 modules.

[tracker1]

https://github.com/dherman/defense-of-dot-js/blob/master/pro...

Though there may need to be some considerations for `exports`/`module.exports` vs the `export` directive.

[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 ;)

[ihsw]

.js, .jsx, .mjs, what's next? .js8?

[inglor]

Node is an open project - why not argue against it there?

[faide]

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

http://wiki.ecmascript.org/doku.php?do=revisions&id=strawman...

[eco]

Reminds me of how leftPad and rightPad were added to D a day or two after the npm story exploded and I thought it was poking fun at the situation but the pull request was actually created many months prior and the person who merged it was unaware of the npm drama. Just a humorous coincidence.

[coldtea]

>* Someone on TC39 has a sense of humor!*

Well, just look at his profile picture:

https://github.com/ljharb

Strong Seth Rogen vibes...

[Hey, I meant it as a complement!]

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

[s3th]

As pointed out below, technically "ECMAScript® 2015" is "ECMA-262 6th Edition", so the numbers still exist in some form. It's a really difficult balance between readability, matching most-common usage in the community (e.g. Kangax still uses ES6), and trying not to mix nomenclatures in the process.

[gsnedders]

IMO it's all a mess. Currently we have "ECMAScript® 2015", which is "ECMA-262 6th Edition".

[petercooper]

ES6 is still somewhat more popular. It's like a lot of terms that catch on even when they're not officially accurate for what they describe (e.g. 'HTML5' covering things like WebGL) - it often pays to go with common usage.

If the end digit had matched, I suspect it would have worked out better, but with ES2015 and ES6 being equivalent, it's pretty confusing.

[DiabloD3]

At least they could have waited a year, so ES6 = ES2016, ES7 = ES2017.

[alexkavon]

No one uses it.

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

[LittleDan]

From the post:

"The V8 team is already working to bring upcoming features such as async / await keywords, Object.prototype.values() / Object.prototype.entries(), String.prototype.padStart() / String.prototype.padEnd() and RegExp lookbehind to the runtime. "

I'm working on async/await in V8, together with Caitlin Potter. Browser support is in progress for Firefox and Safari as well. It didn't make the cut for ES2016, but it is at Stage 3 at TC39. I'm optimistic that it'll get into the main draft specification at the next TC39 meeting after we have a second spec-compliant browser implementation, which doesn't seem very far off.

[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

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

[bzbarsky]

Browsers are adding stack traces across the event loop, precisely because people _do_ commonly want them.

[_mikz]

Unreadable in mobile safari. Way to go.

[dang]

This manages to combine two bad genres of HN comment: the snarky dismissal and the off-topic formatting complaint. Please don't do either of these things here, especially the snark.

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

[coderdude]

Reminds me of how much I hear "this is broken. It does not work on mobile as described." Such a useless assertion. Must be more specific if you find a problem.

[bitmapbrother]

It renders perfectly on my iPhone 6 using Safari.