top | item 14744783

ECMAScript 2017 Language Specification

600 points| samerbuna | 8 years ago |ecma-international.org | reply

241 comments

order
[+] thomasfoster96|8 years ago|reply
Proposals [0] that made it into ES8 (“what’s new”):

* Object.values/Object.entries - https://github.com/tc39/proposal-object-values-entries

* String padding - https://github.com/tc39/proposal-string-pad-start-end

* Object.getOwnPropertyDescriptors - https://github.com/ljharb/proposal-object-getownpropertydesc...

* Trailing commas - https://github.com/tc39/proposal-trailing-function-commas

* Async functions - https://github.com/tc39/ecmascript-asyncawait

* Shared memory and atomics - https://github.com/tc39/ecmascript_sharedmem

The first five have been available via Babel and/or polyfills for ~18 months or so, so they’ve been used for a while now.

[0] https://github.com/tc39/proposals/blob/master/finished-propo...

[+] yahelc|8 years ago|reply
Interesting that String padding made it in -- sort of jumps out as the simplest of these additions. I wonder how much of that had to do with negative PR for JS-land due to left-pad-gate.
[+] a13n|8 years ago|reply
I love the trailing commas for function calls. Wish we could get trailing commas for all of JSON too!
[+] michaelmior|8 years ago|reply
Thanks for sharing! Interesting to me that separate repositories are used for each proposal, which is news to me. Although I can see some nice benefits to doing so.
[+] bjacobel|8 years ago|reply
Please don't call it ES8. It contributes to confusion around the language. ES6 was renamed to ES2015. There is no such spec as ES7 or ES8.
[+] callumlocke|8 years ago|reply
This is mostly symbolic. The annual ECMAScript 'editions' aren't very significant now except as a talking point.

What matters is the ongoing standardisation process. New JS features are proposed, then graduate through four stages. Once at stage four, they are "done" and guaranteed to be in the next annual ES edition write-up. Engines can confidently implement features as soon as they hit stage 4, which can happen at any time of year.

For example, async functions just missed the ES2016 boat. They reached stage 4 last July [1]. So they're officially part of ES2017 – but they've been "done" for almost a year, and landed in Chrome and Node stable quite a while ago.

[1] https://ecmascript-daily.github.io/2016/07/29/move-async-fun...

[+] HugoDaniel|8 years ago|reply
I would really love to see an object map function. I know it is easy to implement, but since they seem to be gaining ranks through syntax sugar, why not just have a obj.map( (prop, value) => ... ) ? :)
[+] thomasfoster96|8 years ago|reply
Is Object.entries(obj).map((prop, value) => ...) close enough? Object.entries is newly standard in ES8.
[+] sghiassy|8 years ago|reply
Perhaps use the new ‘Map’ object in ES6 instead?
[+] kevincennis|8 years ago|reply
I believe that one of the main reasons not to do this is that adding anything to `Object.prototype` means that now everything inherits that new method.

So you have weird things like `'foo'.map()`, `( 42 ).map()`, `new WeakMap().map()`, `false.map()`, etc.

[+] raquo|8 years ago|reply
Adding a `map` method to every single object is not a backwards-compatible change. That's why those new methods are under the `Object` global.
[+] nevir|8 years ago|reply
Until then, lodash.mapValues is your friend :P
[+] ihsw2|8 years ago|reply
Notably, with shared memory and atomics, pthreads support is on the horizon.

https://kripken.github.io/emscripten-site/docs/porting/pthre...

Granted it may be limited to consumption via Emscripten, it is nevertheless now within the realm of possibility.

For this that cannot grok the gravity of this -- proper concurrent/parallel execution just got a lot closer for those targeting the browser.

[+] flavio81|8 years ago|reply
What I wish ECMAScript had was true support for number types other than the default 32-bit float. I can use 32 and 64 bit integers using "asm.js", but this introduces other complications of its own -- basically, having to program in a much lower level language.

It would be nice if EcmaScript could give us a middle ground -- ability to use 32/64 bit integers without having to go all the way down to asm.js or wasm.

[+] pier25|8 years ago|reply
In the last couple of years we've seen a small number of significant improvements like async/await but mostly small tepid improvements like string padding, array.map(), etc. It's like TC39 are simply polishing JS.

I'd like to see TC39 tackling the big problems of JS like the lack of static type checking. I'm tired of looking at a method and having to figure out if it is expecting a string, or an object.

We had EcmaScript4 about 10 years ago with plenty of great features but TC39 killed it. And yeah, it probably made sense since the browser vendor landscape was very different back then. Today it would be possible to implement significant changes to the language much like the WebAssembly initiative.

[+] pi-rat|8 years ago|reply
Really hate the naming for JS standards.. ES2017, ES8, ECMA-262. Way to confuse people :/
[+] ScottBurson|8 years ago|reply
"The versions of Unix are numbered in a logical sequence: 5, 6, 6PWB, 7, 4.1, III, 4.3, V, and V.3." -- quoted from memory from The Unix-Haters Handbook

So you see, they're following long-standing industry practice :-)

[+] wwwigham|8 years ago|reply
ES2017 is the conventional name now that there's annual publications of the spec. ES8 is someone reading the edition number on the document and trying to be terse. ECMA-262 is the formal name of the spec document, not the language the spec defines. All slightly different things, only one of which names the language itself, officially.
[+] gregmac|8 years ago|reply
Is calling it "Javascript" even still correct, or should it be called "ECMAScript"? If someone says they write "Javascript using ES2017" are they talking utter nonsense?

I can find some references to "Javascript" being an implementation of ECMAScript, but doesn't appear to true [1]. Mozilla's implementation is SpiderMonkey, Google's is V8, and Microsoft has Chakra and JScript.

[1] https://en.wikipedia.org/wiki/ECMAScript#Implementations

[+] 43224gg252|8 years ago|reply
Can anyone recommend a good book or guide for someone who knows pre-ES6 javascript but wants to learn all the latest ES6+ features in depth?
[+] stevula|8 years ago|reply
I found it helpful to go through the airbnb style guide. They have lots of examples of the "bad" (often old) way to write something, along with the "good" (often new) way. Then I updated one of my projects to follow those guidelines.
[+] gabergg|8 years ago|reply
http://www.react.express is intended as a learning resource for those used to ES5 Javascript. Granted, it's for learning React through modern Javascript, so it may not be exactly what you're looking for, but it has interactive sections for new ES6 and ES7 features.
[+] jacobwylie|8 years ago|reply
I took a class on ES6 and curated it in a github repo: https://github.com/JacobWylie/ES6

If applicable there are examples of both before and after conventions as well as links to more technical external resources.

[+] samerbuna|8 years ago|reply
exploringjs.com
[+] pgl|8 years ago|reply
Here’s what’s in it: https://github.com/tc39/proposals/blob/master/finished-propo...

And some interesting tweets by Kent C. Dodds: https://twitter.com/kentcdodds/status/880121426824630273

Edit: fixed KCD's name. Edit #2: No, really.

[+] choward|8 years ago|reply
> Edit: fixed KCD's name.

No you didn't.

[+] baron816|8 years ago|reply
Regardless of what gets included in the spec, I hope people think critically about what to use and what not to use before they jump in. Just because something is shiny and new in JS, it doesn't mean you have to use it or that it's some sort of "best practice."
[+] drinchev|8 years ago|reply
For anyone wondering what's NodeJS support of ES8.

Everything is supported, except "Shared memory and atomics"

[1] http://node.green

[+] correctsir|8 years ago|reply
I've been looking at the stage 2 and 3 proposals. I have a difficult time finding use for any of them except for Object spread/rest. The stage 4 template string proposal allowing invalid \u and \x sequences seems like a really bad idea to me that would inadvertently introduce programmer errors. I do hope the ECMAScript standardization folks will raise the barrier to entry for many of these questionable new features that create a maintenance burden for browsers and ES tooling and a cognitive burden on programmers. It was possible to understand 100% of ES5. I can't say the same thing for its successors. I think there should be a freeze on new features until all the browser vendors fully implement ES6 import and export.
[+] rpedela|8 years ago|reply
Has there been any progress on supporting 64-bit integers?
[+] elmigranto|8 years ago|reply
Heck, what about any kind of integers, so we can use bitwise operations without `double -> int -> double` casts?
[+] jadbox|8 years ago|reply
I wish this-binding sugar would get promoted into stage 1.
[+] gregjw|8 years ago|reply
I should really learn ES6
[+] ashnehete|8 years ago|reply
Literally after seeing this on #1 felt like, "Wtf? I just started learning ES6"
[+] emehrkay|8 years ago|reply
I'd like to be able to capture object modifications like Python's magic __getattr__ __setattr__ __delattr__ and calling methods that do not exist on objects. In the meantime I am writing a get, set, delete method on my object and using those instead