
ECMAScript 2017 Language Specification - samerbuna
https://www.ecma-international.org/publications/standards/Ecma-262.htm
======
thomasfoster96
Proposals [0] that made it into ES8 (“what’s new”):

* Object.values/Object.entries - [https://github.com/tc39/proposal-object-values-entries](https://github.com/tc39/proposal-object-values-entries)

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

* Object.getOwnPropertyDescriptors - [https://github.com/ljharb/proposal-object-getownpropertydesc...](https://github.com/ljharb/proposal-object-getownpropertydescriptors)

* Trailing commas - [https://github.com/tc39/proposal-trailing-function-commas](https://github.com/tc39/proposal-trailing-function-commas)

* Async functions - [https://github.com/tc39/ecmascript-asyncawait](https://github.com/tc39/ecmascript-asyncawait)

* Shared memory and atomics - [https://github.com/tc39/ecmascript_sharedmem](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...](https://github.com/tc39/proposals/blob/master/finished-proposals.md)

~~~
a13n
I love the trailing commas for function calls. Wish we could get trailing
commas for all of JSON too!

~~~
WalterSear
What I want are leading commas. Much tidier and one small thing you wouldn't
have to edit/think about when adding and removing list items.

~~~
thekaleb
Unless you need to add something to the beginning.

~~~
WalterSear
I prefer comma first notation.

    
    
        const hello = {
        , 'one'
        , 'two'
        , 'three
        }
    

would be easier to visually parse than:

    
    
        const hello = {
          'one',
          'two', 
          'three',
        }
    

Since the commas actually work as a guide.

------
callumlocke
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...](https://ecmascript-daily.github.io/2016/07/29/move-async-functions-to-
stage-4-per-july-2016-tc39-meeting-tc39-proposals-e8c0354)

~~~
komali2
I don't understand who gets to use these things. We have to support back to
IE11 so other than some things we've managed to find effective polyfills for,
we basically just threw our hands up and code as if it's 2012.

~~~
tracker1
Most modern projects should probably use Babel and a bundler like Webpack for
web targets. You may even want to separate legacy and modern browsers into
separate targets so the 80-90% of users on evergreen browsers get a smaller
download.

~~~
komali2
Yea, we probably should. Too many feature requests, not enough time to let us
clear out the technical debt and make our stack nice and modern :(

~~~
azernik
I'm only two years into my current project and already am feeling this bite
:-\

------
HugoDaniel
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
Is Object.entries(obj).map((prop, value) => ...) close enough? Object.entries
is newly standard in ES8.

~~~
HugoDaniel
Not really object map. Does not return a new object ;)

~~~
thomasfoster96
Ah, well this would return a new object:

    
    
        Object.entries(obj).map((prop, value) => ...).reduce((newOdj, [prop, value]) => newObj[prop] = value);
    

I see your point about verbosity :)

~~~
djfm
Shouldn't it be ".map(([prop, value]) => ...)" ?

I like to write it this way, using as much syntax sugar as possible:

const mapObject = fn => obj => Object.assign( ...Object.entries(obj).map(
([key, value]) => ({ [key]: fn(value) }) ) );

~~~
komali2
>using as much syntax sugar as possible

It's not possible to say this on the internet without being rude so,
apologies, but, why code like that? It genuinely was a struggle to parse (in
my brain) your oneliner of code there. If I found this in our code base it
would be a huge waste of time and energy.

~~~
djfm
No offense taken.

I said I _like_ to write it this way, not that I always do it.

> why code like that

It's a fun exercise.

> it would be a huge waste of time and energy

I don't fully agree on this: from the name and signature it's pretty clear
what the function does, so you don't need to waste time "parsing" the details.
And with unit tests it is also very low-risk.

But that's speculative, in a real project I'd just use lodash.

------
ihsw2
Notably, with shared memory and atomics, pthreads support is on the horizon.

[https://kripken.github.io/emscripten-
site/docs/porting/pthre...](https://kripken.github.io/emscripten-
site/docs/porting/pthreads.html#running-code-and-tests)

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.

~~~
judah
Are locks and mutable shared memory a good thing? Advances in modern
programming languages aim to abstract threads away (e.g. .NET's Task Parallel
Library), because mutable memory shared between threads is a minefield
(atomic, locks, mutexes, compare-exchange, etc.).

Not only are these difficult to reason about and program against, introducing
locks over mutable memory causes performance problems and are a speed bump to
high concurrency. (Heck, just yesterday on HN, a story was published "24-core
CPU and I can't move my mouse" [0] - the culprit? Low-level locks.)

Creating too many threads introduces performance problems, too, thanks to CPU
context switching; pools must be created and threads reused from those pools.

And now in JS land we're trying to _introduce_ threads and mutable shared
memory? Are we just going to learn these lessons over again?

[0]: [https://randomascii.wordpress.com/2017/07/09/24-core-cpu-
and...](https://randomascii.wordpress.com/2017/07/09/24-core-cpu-and-i-cant-
move-my-mouse/)

~~~
imtringued
You can only send strings to webworkers in javascript. Without shared memory
you have to send a serialised copy of your data to the other process which
then has to deserialise it. In most cases this is perfectly fine. But if you
have a lot of data then moving it around might take more time than the
computation itself. In this case you're forced to use shared memory.

~~~
dchest
Not true, you can send ArrayBuffers to webworkers as transferable objects
without copying:
[https://developers.google.com/web/updates/2011/12/Transferab...](https://developers.google.com/web/updates/2011/12/Transferable-
Objects-Lightning-Fast)

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

~~~
arthurdenture
There's a BigInt proposal at stage 2, which might meet some of your needs:
[https://github.com/tc39/proposal-bigint](https://github.com/tc39/proposal-
bigint)

~~~
hzoo
It's parseable in Babel 7, issue to implement the transform is
[https://github.com/babel/proposals/issues/2](https://github.com/babel/proposals/issues/2)

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

~~~
pluma
The reason ES4 was killed was that there was no consensus between the
stakeholders. It would have been a breaking change, making conforming engines
incompatible with all existing JavaScript code.

How well major breaking changes like that work out on the web can be seen by
the massive success ( _cough_ ) of XHTML -- I dare you find me one notable
site correctly using XHTML with the appropriate MIME type (rather than just
sending XHTML as HTML tagsoup using `text/html`).

Web Assembly works because it is not a breaking change to JavaScript. It's
actually defined in a way that is mostly orthogonal to JavaScript -- it shares
some of the APIs but most likely there will be (low-level) APIs only Web
Assembly code can use and some (high-level) APIs that only exist for JS.

~~~
pier25
I'm not advocating for breaking changes, in fact static type checking in ES4
was optional, the language remained just as dynamic if you wanted to use it
that way.

------
pi-rat
Really hate the naming for JS standards.. ES2017, ES8, ECMA-262. Way to
confuse people :/

~~~
ScottBurson
"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 :-)

~~~
komali2
Angular 1, angular 2, angular 2.1... Angular (note, Angular 2 is now Angular!
And so is every version after this! Angular 1 still exists though).

Surface Pro. Surface Pro 2 (note: Surface Pro is now surface pro 1!), Surface
Pro 3, Surface Pro 4, Surface Pro. By the way we also have Surfaces (1, 2, and
3?) as well as Surface Books, and Surface Laptops! :D

Android: here's a bunch of fucking candy

OS: here's a bunch of fucking animals. By the way, sometimes people call your
macbooks 10,1 or some shit.

~~~
smilekzs
> Android: here's a bunch of fucking candy

whose initials follow alphabetical order

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

~~~
skeletonjelly
linkies

[https://github.com/airbnb/javascript](https://github.com/airbnb/javascript)

[https://news.ycombinator.com/item?id=9822975](https://news.ycombinator.com/item?id=9822975)

------
pgl
Here’s what’s in it: [https://github.com/tc39/proposals/blob/master/finished-
propo...](https://github.com/tc39/proposals/blob/master/finished-proposals.md)

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

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

~~~
sjclemmy
If you're a Brit, this is a funny misspelling of Kent's name.

[https://en.wikipedia.org/wiki/Ken_Dodd](https://en.wikipedia.org/wiki/Ken_Dodd)

~~~
pgl
Whoops, that's absolutely why I misspelled it!

------
baron816
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
For anyone wondering what's NodeJS support of ES8.

Everything is supported, except "Shared memory and atomics"

[1] [http://node.green](http://node.green)

~~~
kovek
Shared memory? Is that also maybe going to be implemented on chrome? I would
not have expected shared with code running on the web/in a browser. I'm
confused about the goals of ECMA and how ECMA relates to JavaScript.

~~~
andrewaylett
That's memory shared between the main thread and Web Worker threads. While
it's exciting from an "easily implementing multi-threaded applications" point
of view, given the nature of the objects, it doesn't actually allow sharing
any data that couldn't be shared without the new spec.

------
speg
Is there a "What's new" section?

~~~
samerbuna
The "finished" proposals have a good list:

[https://github.com/tc39/proposals/blob/master/finished-
propo...](https://github.com/tc39/proposals/blob/master/finished-proposals.md)

------
correctsir
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
Has there been any progress on supporting 64-bit integers?

~~~
giaour
The BigInt proposal[0] is stage 2, meaning we should see some implementations
soon.

[0]: [https://github.com/tc39/proposal-
bigint](https://github.com/tc39/proposal-bigint)

------
jadbox
I wish this-binding sugar would get promoted into stage 1.

~~~
empyrical
The :: syntax is one of my favorite proposals - does anyone know what's
holding it up?

------
gregjw
I should really learn ES6

~~~
ashnehete
Literally after seeing this on #1 felt like, "Wtf? I just started learning
ES6"

~~~
Andrex
The additions in ES2016 and 2017 are minimal compared to the massive changes
ES2015 (aka "ES6") introduced. Check the full list of them here:
[https://github.com/tc39/proposals/blob/master/finished-
propo...](https://github.com/tc39/proposals/blob/master/finished-proposals.md)

~~~
ashnehete
Yes, I have been through the proposals. Love these new changes.
Psychologically it still felt daunting when I first saw it! :P

------
ascom
Looks like ECMA's site is overloaded. Here's a Wayback Machine link for the
lazy:
[https://web.archive.org/web/20170711055957/https://www.ecma-...](https://web.archive.org/web/20170711055957/https://www.ecma-
international.org/publications/standards/Ecma-262.htm)

~~~
danielsamuels
If you're using Chrome, you can also go to cache://www.ecma-
international.org/publications/standards/Ecma-262.htm (replacing
[https://](https://) with cache://)

~~~
empyrical
That's just doing a google search, so you could do "cache:{URL}" in firefox's
search field too

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

~~~
z3t4
theres defineproperty in es5. ive used it to create a orm where foo.bar = 1
executes async sql: update foo set x=1

~~~
emehrkay
That sounds pretty cool. Are there any public examples that I can learn from?
Thanks

------
wilgertvelinga
Really interesting how bad the only JavaScript code used on their own site is:
[https://www.ecma-international.org/js/loadImg.js](https://www.ecma-
international.org/js/loadImg.js)

~~~
pcbeef
Do what I say, not what I do.

------
espadrine
I made a short sum-up of changes in this specification here:
[http://espadrine.github.io/New-In-A-
Spec/es2017/](http://espadrine.github.io/New-In-A-Spec/es2017/)

------
lukasm
What is up with decorators?

~~~
thangngoc89
It's now at stage-2

------
komali2
>AWB: Alternatively we could add this to a standard Dict module.

>BT: Assuming we get standard modules?

>AWB: We'll get them.

lol

------
j0e1
> Kindly note that the normative copy is the HTML version;

Am I the only one who finds this ironic..

~~~
mrec
What's ironic about it?

------
idibidiart
Wait, so async generators and web streams are 2018 or 2016?

------
Swizec
Time to update [https://es6cheatsheet.com](https://es6cheatsheet.com)

What's the feature you're most excited about?

~~~
TheCoreh
Definitely async functions. JavaScript code will be _so much cleaner_ thanks
to them. Can't wait for the much needed improvement in readability.

~~~
iso-8859-1
You don't have to wait, it is already supported server-side and client-side.

------
bitL
Heh, maybe JS becomes finally usable just before WebAssembly takes off,
rendering it obsolete :-D

~~~
komali2
Wherein a Hackernews suggests an unknown, unpopular technology will replace a
known, popular one in short order.

~~~
bitL
Come on, many people are looking down at JavaScript for a reason - if the new
standard allows proper multithreading, it suddenly gets closer to "usable"
language as defined by many. But if they had a choice of another language
running on top of Web Assembly (or whatever you name the web's VM), I am not
sure they would even consider learning JS despite it being finally on par with
their favorite language.

------
cies
Nice 90s style website ECMA!

~~~
kronos29296
Its funny that ECMA website is not more modern. Maybe they are too busy with
the spec to change it. Who knows?

~~~
komali2
It's a site read by a bunch of programmers. Why does it need to be pretty? We
can read lightly styled text quite easily. It's how most engineers I know
prefer their _technical documentation._

