Live data from Hacker News

ES6, ES7, and beyond

v8project.blogspot.com

41–50 of 75 posts

Re: ES6, ES7, and beyond

#41
post #17

Earlier quoted context omitted.

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.

Unicode properties are behind an experimental flag: --harmony-regexp-property

Good to know!

Re: ES6, ES7, and beyond

#42

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.

Right, thank you

Re: ES6, ES7, and beyond

#43
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?

Re: ES6, ES7, and beyond

#44
post #43

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

Re: ES6, ES7, and beyond

#45
post #43

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?

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.

Re: ES6, ES7, and beyond

#46
post #3

Unreadable in mobile safari. Way to go.

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.

Re: ES6, ES7, and beyond

#47

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

Re: ES6, ES7, and beyond

#48
post #43

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

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.

Re: ES6, ES7, and beyond

#50
post #36

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

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