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

51–60 of 75 posts

Re: ES6, ES7, and beyond

#51

Post by sfink »

SomeCallMeTim wrote: post #48
calebegg wrote: post #44

Earlier quoted context omitted.

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.

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.

Re: ES6, ES7, and beyond

#52

Post by jay_kyburz »

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…

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.

Re: ES6, ES7, and beyond

#53

Post by snuxoll »

Buttons840 wrote: post #23
WorldMaker wrote: post #13

Earlier quoted context omitted.

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.

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

Re: ES6, ES7, and beyond

#54

Post by snuxoll »

SomeCallMeTim wrote: post #48
calebegg wrote: post #44

Earlier quoted context omitted.

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.

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

Re: ES6, ES7, and beyond

#55

Post by KMag »

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

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

Re: ES6, ES7, and beyond

#56

Post by callahad »

jay_kyburz wrote: post #52
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…

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 implement it in ES5 each time I need it.

Re: ES6, ES7, and beyond

#57

Post by coroutines »

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

Re: ES6, ES7, and beyond

#58

Post by LewisJEllis »

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

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

Re: ES6, ES7, and beyond

#59

Post by seniorsassycat »

spdionis wrote: post #7

> String.prototype.padStart() / String.prototype.padEnd() Finally left-pad module's functionality will be integrated into core! Souns awesome. /s

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.

Re: ES6, ES7, and beyond

#60

Post by elmigranto »

jay_kyburz wrote: post #52
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…

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?

Post reply on HN