Live data from Hacker News

ES6, ES7, and beyond

v8project.blogspot.com

11–20 of 75 posts

Re: ES6, ES7, and beyond

#11
post #3

Unreadable in mobile safari. Way to go.

The gutters are a little small on my iPhone, but I can see all the text. Want to send a screenshot to seththompson [at] google [dot] com? I'll see how much I can fix.

Re: ES6, ES7, and beyond

#12
post #9
post #8

> http://tc39.github.io/proposal-string-pad-start-end/ Not to beat a dead horse, but I find it hilarious that this is a proposal. Someone on TC39 has a sense of humor. Edit: Apparently this was proposed long before left-pad broke the internet.

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.

Re: ES6, ES7, and beyond

#13

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.

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 the top of my head of ALGOL68.

As for Windows 98. Would you seriously with a straight face want to admit to using a version of Windows that is old enough to vote? If anything, it's too bad they stopped that pattern with XP as it would have been a lot easier to shame people for still using Windows 2001 in 2015.

Re: ES6, ES7, and beyond

#14

What happened to the year-based naming convention? I thought we switched to ES2015 and ES2016?

As pointed out below, technically "ECMAScript® 2015" is "ECMA-262 6th Edition", so the numbers still exist in some form. It's a really difficult balance between readability, matching most-common usage in the community (e.g. Kangax still uses ES6), and trying not to mix nomenclatures in the process.

Re: ES6, ES7, and beyond

#15
post #11
post #3

Unreadable in mobile safari. Way to go.

The gutters are a little small on my iPhone, but I can see all the text. Want to send a screenshot to seththompson [at] google [dot] com? I'll see how much I can fix.

[deleted]

Re: ES6, ES7, and beyond

#17
post #7

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

Re: ES6, ES7, and beyond

#18
post #8

> http://tc39.github.io/proposal-string-pad-start-end/ Not to beat a dead horse, but I find it hilarious that this is a proposal. Someone on TC39 has a sense of humor. Edit: Apparently this was proposed long before left-pad broke the internet.

Reminds me of how leftPad and rightPad were added to D a day or two after the npm story exploded and I thought it was poking fun at the situation but the pull request was actually created many months prior and the person who merged it was unaware of the npm drama. Just a humorous coincidence.

Re: ES6, ES7, and beyond

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

Re: ES6, ES7, and beyond

#20
post #17
post #7

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

Unicode properties are behind an experimental flag: --harmony-regexp-property
Post reply on HN