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

61–70 of 75 posts

Re: ES6, ES7, and beyond

#61

Post by jay_kyburz »

callahad wrote: post #56
jay_kyburz wrote: post #52

Earlier quoted context omitted.

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.

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

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.

Re: ES6, ES7, and beyond

#62

Post by jay_kyburz »

elmigranto wrote: post #60
jay_kyburz wrote: post #52

Earlier quoted context omitted.

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.

> windows still 90% of the 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%

Re: ES6, ES7, and beyond

#63

Post by grifter2000 »

snuxoll wrote: post #54
SomeCallMeTim wrote: post #48

Earlier quoted context omitted.

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

Babel certainly can!

https://www.npmjs.com/package/babel-plugin-transform-async-t...

Re: ES6, ES7, and beyond

#64

Post by yoklov »

LewisJEllis wrote: post #58
coroutines wrote: post #57

Earlier quoted context omitted.

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

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.

Re: ES6, ES7, and beyond

#66

Post by inglor »

pornel wrote: post #47
grifter2000 wrote: post #27

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

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

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.

Re: ES6, ES7, and beyond

#67

Post by greggman »

inglor wrote: post #66
pornel wrote: post #47

Earlier quoted context omitted.

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

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.

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

Re: ES6, ES7, and beyond

#68

Post by kansface »

coroutines wrote: post #57
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…

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

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.

Re: ES6, ES7, and beyond

#70

Post by SomeCallMeTim »

snuxoll wrote: post #54
SomeCallMeTim wrote: post #48

Earlier quoted context omitted.

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

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.

Post reply on HN