ES6, ES7, and beyond(v8project.blogspot.com)
v8project.blogspot.com
ES6, ES7, and beyond
http://v8project.blogspot.com/2016/04/es6-es7-and-beyond.html
74 comments
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." ?
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." ?
Yeah, I won't try to speak for Eric or the SpiderMonkey team. Maybe Eric is firmly in support of STC, but in my experience he's very good at going beyond just implementation concerns and considering all the design constraints (one of which is the cost/benefit analysis of new syntax to the user model). IMO the important question isn't who supports what but what's the best outcome. AFAICT, all three of PTC, STC, and no tail calls are on the table, but there's more hashing out to be done.
Your new wording seems totally fine -- sorry if I was pedantic, and I'm really not bent out of shape about your blog post. I just want to be sure that people don't get confused about where things stand. New features such as STC require time to bake (which is part of what the multi-stage lifecycle for proposals is all about) -- I only meant to clarify the state of the discussion.
Edit: Grrr, re-reading this it still feels like I'm speaking for Eric. He's his own guy, I should shut up about his position! All I mean to say is, I don't think anyone should be staking out strong positions at this point in syntax design. The design process is iterative and uncovers new constraints and effects, and we should all keep open minds and work collaboratively. I'm open to all possible outcomes: PTC, STC, no tail calls at all. Tricky space!
Your new wording seems totally fine -- sorry if I was pedantic, and I'm really not bent out of shape about your blog post. I just want to be sure that people don't get confused about where things stand. New features such as STC require time to bake (which is part of what the multi-stage lifecycle for proposals is all about) -- I only meant to clarify the state of the discussion.
Edit: Grrr, re-reading this it still feels like I'm speaking for Eric. He's his own guy, I should shut up about his position! All I mean to say is, I don't think anyone should be staking out strong positions at this point in syntax design. The design process is iterative and uncovers new constraints and effects, and we should all keep open minds and work collaboratively. I'm open to all possible outcomes: PTC, STC, no tail calls at all. Tricky space!
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()
I'm from Lua originally and we've had tail calls forever... why would you point them out? It should be obvious:
return wat()
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!)
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!)
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.
As the article pointed out, the ternary operator, lambdas, and &&/|| make it easy to miss a tail call. I tend to agree with you - the later will see reduced use with named arguments while optimizing for the former doesn't make much sense.
> String.prototype.padStart() / String.prototype.padEnd()
Finally left-pad module's functionality will be integrated into core! Souns awesome. /s
Finally left-pad module's functionality will be integrated into core! Souns awesome. /s
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.
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.
People writing polyfil's to add padStart to String.prototype used left-pad.
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.
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.
I was thinking these features are still 5+ years away unless you are prepared to actually ask your users to switch to Chrome.
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.
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.
Technically, default arguments don't <em>quite</em>, <em>purely</em>, desugar exactly into that -- there are some scoping complexities to them as well (possibly only for functions having strict mode code), the details of which I haven't fully internalized. Your observation is otherwise correct with a little bit of handwaving. :-)
Absolutely agree, I was just confused by "all major desktop browsers will have support of the big ticket ES6 features" but I didn't think IE10 or 11 were getting any of these features.
> I need it.
Need is a strong word.
Need is a strong word.
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. :)
If I need that pattern, I'd rather write it declaratively than imperatively. :)
Variable arity is exactly the thing to which I refer. It isn't needed.
> windows still 90% of the market
Of all the people on the web, or target audience of your website, or what market?
Of all the people on the web, or target audience of your website, or what market?
I just checked my own stats. Chrome 62%, Safari 18.5, Firefox 10% Internet Explorer 3%
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.
PLEASE don't do the awkward .mjs thing. I and prob most devs will simply not respect it.
Node is an open project - why not argue against it there?
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.
But yes, Node.js team, please don't inflict .mjs on us, or let your extreme NIH block the introduction of ES2015 modules.
Right, thank you
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.
Though there may need to be some considerations for `exports`/`module.exports` vs the `export` directive.
.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 ;)
Seems like a good fit for EcmaScript. It might even help finally renaming the language, so that tech recruiters confuse it with something else ;)
> so that tech recruiters confuse it with something else
At least if a recruiter starts asking you about your Eczema experience, you can more easily determine that the screening process has gone off the rails.
At least if a recruiter starts asking you about your Eczema experience, you can more easily determine that the screening process has gone off the rails.
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.
Although it's a cute suggestion.
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
> 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.
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.
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...
https://github.com/tc39/proposal-string-pad-start-end/commit...
http://wiki.ecmascript.org/doku.php?do=revisions&id=strawman...
>* 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!]
Well, just look at his profile picture:
https://github.com/ljharb
Strong Seth Rogen vibes...
[Hey, I meant it as a complement!]
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.
Is there already a proposal for (optional) type safety? So we can assimilate the typescript fans?
What happened to the year-based naming convention? I thought we switched to ES2015 and ES2016?
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.
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.
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.
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.
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?
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?
Common table expressions, not "with statements", sorry to be pedantic. Also, CTE's are awesome - I used them pretty heavily in massaging a self-referential table used to implement a hierarchy into something that doesn't piss off reporting tools (to make things worse it's a slowly changing dimension, oh the fun).
As I understand the reason they switched to the year based naming is because they plan to do yearly standards now, switching to a release date based model rather than a feature based model. C++ has kind of switched to this model too, where features that are ready to go for the release date are included, and ones that aren't quite baked enough will not hold up the release, to help avoid an ES6 type situation where the committee works for years and years without releasing an update.
So it's not that standards become out of date, especially as in both Javascript and C++'s case, the standards are generally additive. They just add stuff so your old software should continue to work and will not become "out of date".
Anyway, that's the reasoning I've been given behind the change and it makes sense to me. Hopefully that answers the question for you as well.
So it's not that standards become out of date, especially as in both Javascript and C++'s case, the standards are generally additive. They just add stuff so your old software should continue to work and will not become "out of date".
Anyway, that's the reasoning I've been given behind the change and it makes sense to me. Hopefully that answers the question for you as well.
How about C++?
C++03
C++11
C++14
C++17
Ubuntu?
16.04
13.10
9.04
C++03
C++11
C++14
C++17
Ubuntu?
16.04
13.10
9.04
No one uses it.
IMO it's all a mess. Currently we have "ECMAScript® 2015", which is "ECMA-262 6th Edition".
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.
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.
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.
At least they could have waited a year, so ES6 = ES2016, ES7 = ES2017.
>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.
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.
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?
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
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.
It's even more of a step forward than Promises was.
As the article described, JS engines are not implementing features in "spec order". I expect async/await to get wide support fairly soon. (Though my opinion doesn't count for much. I work on SpiderMonkey, but I'm not the one who'd be finishing up our implementation, and I don't know where JSC and Chakra are on it.)
It's a bit of a funky one because it expands the scope of ES into what has traditionally been rendering engine territory (as in, an event loop). But I haven't seen resistance to it.
It's a bit of a funky one because it expands the scope of ES into what has traditionally been rendering engine territory (as in, an event loop). But I haven't seen resistance to it.
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).
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).
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.
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.
Babel certainly can!
https://www.npmjs.com/package/babel-plugin-transform-async-t...
https://www.npmjs.com/package/babel-plugin-transform-async-t...
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.
"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.
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?
Why do we need explicit tail calls with stack traces?
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.
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.
Browsers are adding stack traces across the event loop, precisely because people _do_ commonly want them.
Unreadable in mobile safari. Way to go.
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.
[deleted]
It renders perfectly on my iPhone 6 using Safari.
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.
Yes, be more specific, but also there's no point in posting it here. Email the site maintainer to let them know, HN is not a tech support forum or a bug tracking system.
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.
FWIW, this:
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.