Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

ES6, ES7, and beyond

v8project.blogspot.com

Post reply on HN
Print view View original

21–30 of 75 posts

Re: ES6, ES7, and beyond

#21

Post by jgon »

have_faith wrote: post #4
lucasmullens wrote: post #2

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.

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.

Re: ES6, ES7, and beyond

#23

Post by Buttons840 »

WorldMaker wrote: post #13
have_faith wrote: post #4

Earlier quoted context omitted.

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 t…

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.

Re: ES6, ES7, and beyond

#24

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

Re: ES6, ES7, and beyond

#25

Post by zghst »

grayrest wrote: post #19

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…

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.

Re: ES6, ES7, and beyond

#26

Post by dherman »

faide wrote: post #12
calebegg wrote: post #9

Earlier quoted context omitted.

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

Good catch, I stand corrected.

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

Re: ES6, ES7, and beyond

#29

Post by LittleDan »

dherman wrote: post #24

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

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

Re: ES6, ES7, and beyond

#30

Post by stupidcar »

grifter2000 wrote: post #27

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

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.

Post reply on HN