
Examples of everything new in ECMAScript 2016, 2017, and 2018 - node-bayarea
https://medium.freecodecamp.org/here-are-examples-of-everything-new-in-ecmascript-2016-2017-and-2018-d52fa3b5a70e
======
oneeyedpigeon
> Trivia: the JavaScript spec people wanted to name it contains, but this was
> apparently already used by Mootools so they used includes

That sounds ... unfortunate, to say the least. Why is the language spec.
beholden to one framework written in that language? Doesn't mootools [1] check
first for functions it might be overriding?

> Emojis and other double-byte chars are represented using multiple bytes of
> unicode. So padStart and padEnd might not work as expected!

It's a shame this isn't followed up on. What's the solution? Only use ASCII?
Don't use padStart/padEnd? Does anyone know anything about monospace fonts and
any guarantees they make wrt. unicode?

[1]
[https://mootools.net/core/docs/1.5.2/Types/Array#Array:conta...](https://mootools.net/core/docs/1.5.2/Types/Array#Array:contains)

~~~
thrownaway954
"but this was apparently already used by Mootools so they used includes"

serious question... does anyone even use mootools at this point in time to
even consider this? seems like more and more people are going leaving jquery
for vanilla javascript everyday, so i have to conclude that jquery itself will
eventually run it's course, like prototype did, and die off, but i would have
thought that mootools died long ago.

~~~
stareatgoats
Approx 460,000 websites [0]. Among them jsfiddle.net, tripadvisor.com.

[0]
[https://www.wappalyzer.com/technologies/mootools](https://www.wappalyzer.com/technologies/mootools)

------
hackcasual
Don't get too excited for SharedArrayBuffer. Every major browser disabled it
to help mitigate spectre, and there's no current road map for re-enablement.

~~~
matlin
I hope they scrap it for a better model. Shared memory + locks is not the only
way to handle concurrency and can be difficult to reason about. I don't quite
understand what problem it's solving that message passing doesn't already.

Anyone have any insight on this?

~~~
nteon
It isn't the only way to handle concurrency, but they are the only primitives
that can be used to port existing code (C/C++/Rust/etc) into the browser
sandbox without killing performance, or introducing crazier and unsound
primitives (like stack manipulation).

I've used SharedArrayBuffers to port things like latex into the browser (
[https://browsix.org](https://browsix.org) ), and without it you can't use
wasm or asm.js, you need to interpret C code in JavaScript to save/restore the
stack on system calls.

~~~
dragonwriter
> It isn't the only way to handle concurrency, but they are the only
> primitives that can be used to port existing code (C/C++/Rust/etc) into the
> browser sandbox without killing performance

I thought a big reason why we have WASM is so that that emphatically does not
need to be a concern of JS.

------
keyle
I'm surprised we don't have the 'safe navigation operator' yet in Javascript.

It would be very useful, especially in templating engines, complex VueJS views
etc.

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

~~~
nimos
There is a proposal out for it:

[https://github.com/tc39/proposal-optional-
chaining](https://github.com/tc39/proposal-optional-chaining)

~~~
scottmf
This is one of my favorite proposals, along with the pipe operator and partial
application proposals:

    
    
      const add = (x, y) => x + y;
      const addTwo = add(2, ?);
      let x = addTwo(5); // 7
      
      x = 5 |> addTwo |> add(?, 10); // 17
    

The last example is equivalent to:

    
    
      add(addTwo(5), 10);
    

Obviously the pipe operator is more useful when order matters.

~~~
mafro
Although I expect you're presenting a contrived example, I find that syntax
horrible. In your example it provides no additional value, and requires more
typing. And more thinking to parse.

~~~
geoelectric
Which aspect, the partial or the pipeline?

The partial application operator clearly wins over bind, IMO, which is
currently the way you'd do that [ addTwo = add.bind(this, 2) ] if only because
you don't need to specify the this parameter. It also gives the option to
"bind" to other parameters than the leftmost.

The pipeline operator in that example is a little contrived, but coming from
any functional background it makes a ton of sense. Depending on what I was
piping, I might also format it more like:

    
    
        x = 5 
          |> addTwo
          |> add(?, 10)
    

...which would probably resonate with anyone used to promise chains:

    
    
        x = Promise.resolve(5)
          .then(addTwo)
          .then(add(?, 10)) // or v => add(v, 10)
    

It's still contrived, but it is a reasonably familiar flow in JS. It would
also clean up async/await syntax a lot assuming they could be used together:

    
    
        x = await foo(await bar(2, await baz(3))) 
    

...becomes...

    
    
        x = await baz(3)
          |> await bar(2, ?)
          |> await foo(?)
    

...which honestly is a more accurate representation of what's happening.

~~~
mafro
Thanks for the expanded examples. Maybe I'll like it once I see it in the wild
solving real problems.

------
Avery3R
Gigantic sticky header and footer and a huge font size? You can barely fit a
single paragraph on the page, this is probably one of the worst website
designs that I've ever seen.

~~~
jake-low
You might like this extension [0] for Firefox and Chrome that removes the
sticky header and footer from Medium sites.

[0]: [https://github.com/thebaer/MMRA](https://github.com/thebaer/MMRA)

~~~
zengid
Also goes away if you log into Medium.. but your suggestion is better if you
don't want to set up a login!

------
Flimm
> This is because ️ is two bytes long ('\u2764\uFE0F' )!

No, that's not bytes. You're counting code points. Because of the way
Javascript works, it can't accept code points greater than U+FFFF, so it has
to use surrogate pairs.

~~~
sjrd
Nope, nothing to do with surrogates either. Surrogates are code points encoded
with 2 code _units_ of 2 bytes each. A number of emoji, like the heart, are
coded using multiple code _points_ , which is even more bizarre.

~~~
masklinn
> Nope, nothing to do with surrogates either. Surrogates are code points
> encoded with 2 code units of 2 bytes each.

Surrogates are actual codepoints, the range U+D800 to U+DFFF is reserved
exclusively for that use:
[https://en.wikipedia.org/wiki/Universal_Character_Set_charac...](https://en.wikipedia.org/wiki/Universal_Character_Set_characters#Surrogates).

> A number of emoji, like the heart, are coded using multiple code points,
> which is even more bizarre.

Not really. It's a base codepoint plus some sort of combining/variation
selector, not unlike e +‌ ‌́ = é e.g. U+2764 HEAVY BLACK HEART (which HN
strips because as of 2018 HN's commenting system remains hot garbage) + U+FE0F
VARIATION SELECTOR-16 = a red heart. That mechanic is also used to select skin
tones on "people" emoji e.g. take U+1F476 BABY, add U+1F3FD EMOJI MODIFIER
FITZPATRICK TYPE-4 and blamo light-brown baby. This allows a multiplicity of
variants when useful without having to implement each combination
individually.

There _are_ emoji which are actually coded using multiple codepoints (not a
base + modifiers): the country flags, which are pairs of regional indicator
symbols composing ISO-3166 country codes e.g. U+1F1F1 REGIONAL INDICATOR
SYMBOL LETTER L + U+1F1F8 REGIONAL INDICATOR SYMBOL LETTER S = 🇱🇸 (the flag of
lesotho). Unpaired regional indicators display as crummy placeholders at best,
they're not just modified, here's with an interstitial space: 🇱 🇸

"Family" emoji take it one step further (and into the "hack" realm imo),
they're a bunch of independent emoji (possibly with their own variation
selectors) "joined" by ZJW.

~~~
sjrd
> Surrogates are actual codepoints, the range U+D800 to U+DFFF is reserved
> exclusively for that use:

Yes ... and no. In a UTF-16-encoded string, surrogates lose their status of
code point (which they would have in a UTF-32- or a UCS-2-encoded string) and
are mere code units instead.

The fact that the natural number they represent is reserved as code points is
only a trick to band-aid systems that are trying to interpret buffers as UCS-2
although they are UTF-16.

> Not really. It's a base codepoint plus some sort of combining/variation
> selector, not unlike e +‌ ‌́ = é

I am pretty sure the combining marks and all these other things are
technically still _code points_ on their own. They're not _glyphs_ , though: a
glyph can be represented by multiple code points, as you mentioned one base
code point (or two as in the flags) and potential combining
marks/selectors/etc.

And then the families are indeed multiple glyphs with ligatures, AFAIU.

------
ridiculous_fish
The ECMAScript spec is weird. One example: in ES5 RegExp.prototype was itself
a RegExp, in ES6 it became not a RegExp but just an Object, and in ES7 it
stayed an Object but all of the RegExp.prototype methods have to specially
check if `this` is RegExp.prototype, thereby pretending to be a RegExp,
without actually being one.

Why does the spec have this churn?

~~~
spiralx
I suspect it might have something to do with allowing developers to extend the
built-in types - I know that changes were made between ES5 and ES6 to allow
subclassing Array, could well be the same issue. See Symbol.species for
instance.

Wait, it's actually most likely because in ES6 you can use `new RegExp()` as
well as `RegExp()` to create a new object.

------
mrtksn
That’s nice, lately I start forgetting what’s ECMAScript and what’s
Babel/Webpack feature.

Sometimes it’s nice to have a refresh.

------
elmigranto
Can someone please explain why for…of needed to be specialized for its async
form?

I get why async generators & iterators won't work with plain for…of, but don't
get why following is invalid:

    
    
        for (const i of [1, 2, 3])
          await getThingAtIndex(i);
    

The very last example in the article uses similar code, but I feel iterating
over array of promises misses the point (as opposed to actually receiving
async iterator with `async next () {…}` via `Symbol.iterator`).

Or am I missing something here? Thanks.

~~~
spiralx
Your example is equal to

    
    
      await getThingAtIndex(1)
      await getThingAtIndex(2)
      await getThingAtIndex(3)
    

whereas the async for loop is equivalent to

    
    
      await Promise.all([
        getThingAtIndex(1),
        getThingAtIndex(2),
        getThingAtIndex(3)
      ])
    

Your example is valid syntax, but it executes each call synchronously.

~~~
xeromal
The article says `This feature adds a new “for-await-of” loop that allows us
to call async functions that return promises (or Arrays with a bunch of
promises) in a loop. The cool thing is that the loop waits for each Promise to
resolve before doing to the next loop.`. which seems to be in contention with
what you say.

------
jaequery
i personally think javascript ECMAScript committee needs to take a break and
chill for a bit. they are changing too fast. it's to the point one forgets if
a certain new syntax is available in the whatever version they are and need to
check the manual several times. it was fine from es5, 6,7, but if this keeps
up at this rate, it's getting too much.

~~~
h1d
Seems you're tired of the entire JS ecosystem.

JS itself was in need of updates as it was completely left behind against many
of modern languages despite still being in the center of the web.

You see how there are so many AltJS and transpilers because plain JS was
dragging behind.

~~~
megaman22
Yet we're always transpliling JS anyway, all the time, for browser support.
Might as well just bite the bullet and leave it as a compilation target and
use something better, with less foot-guns.

------
kristiandupont
I really don't understand the need for the infix exponentiation operator.
Maybe it's because I just don't do calculation heavy JS code but it seems like
nothing but a clever little trick you can impress colleagues with. I would
hate for JS to evolve towards needing something like
[https://www.ozonehouse.com/mark/periodic/](https://www.ozonehouse.com/mark/periodic/)

------
kuon
I see JS becoming more and more complex, while elm becomes more and more
simple, yet it can do a lot.

------
collyw
Fixed header and footer wastes enough screen space on a laptop that it makes
it annoying to read.

------
dmix
> Until now, if we want to share data between the main JS thread and web-
> workers, we had to copy the data and send it to the other thread using
> postMessage . Not anymore!

This would have been great for a complex Chrome web extension (Gmail "AI"
plugin) I developed previously. It relied on quite a significant amount of
postMessage'ing back/forth where I had to create a hand-built queue system (on
both ends) with redundancy and debugging. And even then I still had a endless
series of race conditions and silently failing bugs that were difficult to
debug :/

------
collyw
Question from a backend dev who need to do some JavaScript from time to time.

What version should I use? With backend stuff I am usually responsible for
installing the versions of the code / language / libraries that I use. With
browsers what can I reasonably expect users to have in their browser?

~~~
nostalgeek
> What version should I use? With backend stuff I am usually responsible for
> installing the versions of the code / language / libraries that I use. With
> browsers what can I reasonably expect users to have in their browser?

this is a tricky question. You need to test each feature you want to use on
targeted browsers, really.

Or use a specialized compiler that will compile your javascript to a former
version of the language (a tool like babel does that).

A site like [https://caniuse.com](https://caniuse.com) can help you identify
which feature works on what browser.

But at the end of the day, it's like DOM API, your scripts need to be tested
and errors monitored in production.

~~~
collyw
Thanks, that site looks useful.

------
ceruleus
In the ES2018 section, there are 2 #8s.

------
wotbbcicxinu
Thanks. I didnt realize some of those 2018 examples just got in. Im really
enjoying the object helpers

------
ransom1538
Nice almost as good as PHP. I loved the whole get keys segment.

~~~
_sdegutis
Almost as good? I'm really curious what PHP has over JS at this point...

~~~
nnq
Simple execution model for server-side apps: each request is practically a
separate process, sharing nothing with the others... so basically you can even
have an infinite loop in the code specific for one request, some code calling
an extension that leaks memory in the code for another etc. The bugs keep
piling, but your app keeps mostly workin' ;)

It's in a way like lambda/serverless but on any random server.

I'm kind of sad this model of "shared nothing" \+ "something just runs your
code" has never carried on to other more enjoyable languages...

~~~
PaulStatezny
> Simple execution model for server-side apps: each request is practically a
> separate process, sharing nothing with the others

It occurs to me that this isn’t a technical impossibility with JavaScript. It
wouldn’t be difficult to write a library that spins up a new node process for
each request. It’s just less efficient and goes against the grain of the
language. (Having asynchronous IO)

------
EtDybNuvCu
I am pleased to see that features from E continue to be smuggled into ES, like
finally-style asynchronous cleanup and template literal enhancements.

Edit: Downvotes can't undo our improvements to ES. We will drag JavaScript and
its users, kicking and screaming, to a capability-secure future.

~~~
recursive
Of all the languages that have these features, how do you conclude that ES is
"smuggling" from E, a language I've never heard of before?

~~~
EtDybNuvCu
I get to be part of the discussions since I hack on E-related things.

Mark Miller worked on E and then on Google's Caja (stands for 'Capability
JavaScript'). He has been leading an effort to port features from Caja into ES
via the 'Secure ECMAScript' initiative:
[https://github.com/drses](https://github.com/drses)

Doug Crockford worked on E and ported E's data mini-language, TermL, to JS and
it became JSON. He's also done many other things in the JS community. The
json.org website still links into the E archeological site from its front
page:
[http://erights.org/data/terml/embeddings.html](http://erights.org/data/terml/embeddings.html)

The WeakMap feature of ES doesn't mention it in the spec [0], but the
'sealer/unsealer' capability pattern can be implemented on top easily, and in
fact having WeakMap is equivalent to having E's brand-maker or Monte's
makeBrandPair, as discussed here:
[https://groups.google.com/forum/#!topic/cap-
talk/4hPYemjPK_Y](https://groups.google.com/forum/#!topic/cap-
talk/4hPYemjPK_Y)

[0] [https://www.ecma-international.org/ecma-262/6.0/#sec-
weakmap...](https://www.ecma-international.org/ecma-262/6.0/#sec-weakmap-
objects)

~~~
masklinn
> Mark Miller worked on E and then on Google's Caja (stands for 'Capability
> JavaScript'). He has been leading an effort to port features from Caja into
> ES via the 'Secure ECMAScript' initiative:
> [https://github.com/drses](https://github.com/drses)

So nothing to do with current ES, and if anything a dead effort, the "Secure
ECMAScript" repository hasn't seen an update in 5 years.

> Doug Crockford worked on E and ported E's data mini-language, TermL, to JS
> and it became JSON.

Do you have any evidence for those assertions as explanations, rather than the
rather obvious and much simpler "he was looking for a data format to
communicate between frontend and backend and javascript literals could be
trivially and quickly eval'd from the client"?

> The json.org website still links into the E archeological site from its
> front page:
> [http://erights.org/data/terml/embeddings.html](http://erights.org/data/terml/embeddings.html)

Insultingly misleading. json.org links to that page from a section on json
implementations in various languages, because that page has a section on "json
in terml". In fact, that's the exact label of the link on json.or. It also
links to pages for labview, M or PascalScript, that doesn't mean JSON traces
its roots to any of those.

> The WeakMap feature of ES doesn't mention it in the spec [0] but the
> 'sealer/unsealer' capability pattern can be implemented on top easily

You can implement stuff on top of existing features, news at 11.

> and in fact having WeakMap is equivalent to having E's brand-maker or
> Monte's makeBrandPair

Of course WeakMap is also and more directly equivalent to having weak maps
from dozens of preceding language.

Your comment distinctly looks like you're just seeing everything through the E
lens because you really want it to be relevant, and hammering the ES peg in
the E hole no matter how the fit is.

~~~
EtDybNuvCu
I'm not gonna bother quoting you to fisk you. Your approach towards my
evidence is weak overall. I'm gonna throw more evidence at you.

Miller and Dean Tribble have been working on WeakRefs lately:
[https://github.com/tc39/proposal-weakrefs](https://github.com/tc39/proposal-
weakrefs)

Crockford's personal site no longer has the original JSON description, and
neither does the Wayback Machine, but his site does still have a section on E:
[http://www.crockford.com/](http://www.crockford.com/)

In this talk [0], Crockford discusses the origin of JSON. He mentions working
with Chip Morningstar (this guy [http://habitatchronicles.com/2017/05/what-
are-capabilities/](http://habitatchronicles.com/2017/05/what-are-
capabilities/)) and has oblique references to his prior work. He doesn't
bother to explain what he was doing during the 90s here, and at this point
social interaction becomes required to learn more.

'hammering the ES peg in the E hole' is wrong. They're hammering the E peg
into the ES hole. Not all of us believe in this approach; some of us think
that JS is irredeemable and that we should keep iterating with languages like
Pony and Monte which expand on the original E concepts.

Like I said, kicking and screaming. I don't know _why_ you all kick and scream
so much, but you do.

[0]
[http://www.youtube.com/watch?v=-C-JoyNuQJs](http://www.youtube.com/watch?v=-C-JoyNuQJs)

~~~
recursive
I've got nothing against E. But I have some ideas about why "we all" kick and
scream so much. I think it's got something to do with the way you're packaging
your message. If you start with an adversarial tone, there's a good chance the
rest of the discourse will go that way too.

And I don't even like javascript.

