PLEASE don't do the awkward .mjs thing. I and prob most devs will simply not respect it.
.js, .jsx, .mjs, what's next? .js8?
ES6, ES7, and beyond
31–40 of 75 posts
Re: ES6, ES7, and beyond
#32(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 disc…
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…
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!
Re: ES6, ES7, and beyond
#33What 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.
How about C++?
C++03
C++11
C++14
C++17
Ubuntu?
16.04
13.10
9.04
Re: ES6, ES7, and beyond
#34What happened to the year-based naming convention? I thought we switched to ES2015 and ES2016?
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.
Re: ES6, ES7, and beyond
#35Unreadable in mobile safari. Way to go.
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.
Re: ES6, ES7, and beyond
#36The 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?
Re: ES6, ES7, and beyond
#37PLEASE don't do the awkward .mjs thing. I and prob most devs will simply not respect it.
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.
Re: ES6, ES7, and beyond
#38The 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 trace…
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.
Re: ES6, ES7, and beyond
#39>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.
Re: ES6, ES7, and beyond
#40> String.prototype.padStart() / String.prototype.padEnd() 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.
I do support the addition. It's an useful feature. Just couldn't stop myself :).