
ECMAScript 2016+ in Firefox - robin_reala
https://blog.mozilla.org/javascript/2017/02/22/ecmascript-2016plus-in-firefox/
======
shadowmint
Realistically, when are we going to see the modules situation resolved?

ES2017?

ES2018?

I know, I know, just use a transpiler and emit a bundle... but really?

It's been a draft since 2015, and no browsers have _any_ support for it yet,
despite full support for the rest of the standard?

Are modules really that controversial?

I'm kind of disappointed, honestly, that despite all the progress in the
ecosystem, this long standing issue still remains mysteriously unsolved, by
anyone.

If you're using a transpiler anyway, who really cares if you have native
support for the language features?

~~~
JoshGlazebrook
Forget about browsers, have you read the clusterfuck that Node.js is aiming
for with ES6 Modules?

[https://medium.com/the-node-js-collection/an-update-on-
es6-m...](https://medium.com/the-node-js-collection/an-update-on-es6-modules-
in-node-js-42c958b890c#.afjuek8br)

~~~
mstade
It really is a shame isn't it? I'm not sure why the unambiguous syntax
proposal was shot down – there were good reasons I'm sure – but I thought it
was a pretty solid idea.

------
nailer
I can see that strict mode inside a function using default parameters should
throw according to the spec ( [https://tc39.github.io/ecma262/#sec-function-
definitions-sta...](https://tc39.github.io/ecma262/#sec-function-definitions-
static-semantics-early-errors)) but does anyone know why? Is strict mode
something we should now be avoiding?

~~~
swhipple
See here [1], under "Why make this change?".

[1] [https://www.nczonline.net/blog/2016/10/the-
ecmascript-2016-c...](https://www.nczonline.net/blog/2016/10/the-
ecmascript-2016-change-you-probably-dont-know/)

~~~
nailer
Ah that makes sense - by the time the parser sees a 'use strict' it's too late
to apply strict mode to the default arguments. Thanks!

------
cdnsteve
Async Functions Status: Available from Firefox 52 (now Beta, will ship in
March 2017).

------
M4v3R
Good to see such quick progress in this area in major browsers. It's worth
noting that WebKit also has 100% support for ES 2016+. So now only Edge is
lagging in this regard.

[0] [http://kangax.github.io/compat-
table/es2016plus/#webkit](http://kangax.github.io/compat-
table/es2016plus/#webkit)

~~~
pjmlp
It doesn't help when one needs to target enterprise markets or devices that
only have their factory provided browser.

~~~
paol
That's what Babel[0] is for. Realistically you can't rely on native ES2016 for
any target audience yet, but with Babel you can blissfully live in the future,
today :)

Also, thrown in core-js[1] while you're at it.

[0] [https://babeljs.io/](https://babeljs.io/)

[1] [https://github.com/zloirock/core-js](https://github.com/zloirock/core-js)

~~~
pjmlp
Babel is only part of the history, then there is HTML and CSS support levels.

Some of our projects are with customers that still rely on XP with IE 8,
require using the "Internet Browser" for pre-Android 4.4 or Windows Safari (!)
or IoT devices without updatable browsers.

~~~
myared
Your customers are lucky to have you. I imagine they will rely on XP and IE8
as long as you are around.

~~~
pjmlp
Not me personally, my employer is quite big, and any consulting company will
happily sell such services.

------
rocky1138
Do any of these changes make the language objectively better? All I see are
nice-to-haves that aren't really required.

~~~
mrspeaker
I've always had a soft-spot for JavaScript, and have written a tonne of it
over the years - all these "nice-to-haves" are really nice to have. I find it
a lot more fun to write and, more importantly, easier to read six months later
(assuming people don't try to be overly tricky with it: I'm looking at you,
nested-destructed function parameters!)

------
hatsunearu
I like how they added (what is essentially) left pad. Hah!

------
scanr
I'm unreasonably happy about Async Iterators being on the roadmap. Makes it
much easier to write imperative asynchronous streaming code.

------
andrzejsz
I wonder does ECMAScript 2017 has optional name ES8?

~~~
mstade
Not really, but there's certainly an off-by-one joke in there somewhere.

Since ES2015 the official nomenclature is ES<year>, to convey that a new
version of the standard is cut yearly. While this may result in somewhat
underwhelming releases, like ES2016, at least it's much easier to reason about
and target than previously. Case in point, it took ten years or so to get from
ES3 to ES5, and another five-six years I believe to get to ES2015.

These were substantial releases to be sure, but for a long time the
uncertainty about when a spec draft was considered done was anything but fun,
and I for one applaud the new nomenclature and process for being much, much
easier to reason about and target.

~~~
jakub_g
We must stop using names like ES8 etc. _right now_ , otherwise there'll be a
lot of confusion in 4024 about which version of ES your customers' IE
supports.

~~~
u02sgb
Surely we'll get there in 2020 or 2021, is that ES10, ES11 or ES20, ES21?

Edit: and yes I know you were joking :)

------
SimeVidas
Async iteration is already at Stage 3? Nice.

