ECMAScript 2016+ 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?

[mstade]

Note to people reading this: module support in this post seems to mostly refer to the loading of modules. The spec is pretty clear about the syntax and semantics of modules, except when it comes to loading which it more or less says is "up to the runtime" to figure out.

There's some interesting (or not, depending on your POV) conversation/debate going on between the nodejs world and the browser world, which are – I suppose – the only two "real" runtime environments where JS is widely used.

There's a lot of effort going into figuring this out, but from a lowly developer point of view it's increasingly frustrating to see that two years on from when the module standard was ratified, we still have to resort to compiling modules to a yesteryear solution such as AMD, CJS, or even globals – or, if you're so inclined, all at once via UMD.

One big issue in figuring this out, as far as I understand it, is determining whether some JS code is ES2015+ or not, since the semantics of loading such a module changes. It may sound simple, but there's plenty of situations where the answer is ambiguous, but picking the wrong answer will result in a change of behavior for older code. Since TC39 is very wary of not breaking backwards compatibility (and kudos to them for it!) simply saying something like "assume ES2015" just won't do.

There was a proposal to change the module semantics to require ES2015 modules to include at least one import or export statement, since these would break in pre-ES2015 runtimes, removing any ambiguity in the syntax. Unfortunately, it seems this proposal is all but dead at this point. (And probably for good reasons I simply don't know about.)

DISCLAIMER: I may well be incorrect about the details in the above, but I think the overall picture is more or less correct.

[hzoo]

The purpose of Babel/transpilers is to eventually allow users to use the native versions of language features. Native support will eventually be faster (not at first), will result in less code sent to users (compiled code is larger), and easier to debug (don't need sourcemaps).

https://v8project.blogspot.com/2017/02/high-performance-es20...

I made https://github.com/babel/babel-preset-env to make it easier to transition. Hoping that Babel makes it easier to not have to think about whether you are using native or not, so we'll work on that workflow.

[evilpie]

Preliminary modules supports can be enabled in Firefox Nightly by changing dom.moduleScripts.enabled to true in about:config. There are still some bugs (https://bugzilla.mozilla.org/show_bug.cgi?id=568953) to fix before we can ship this.

[pjmlp]

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

Looking forward to the day alternative languages start targeting WebAssembly instead of JavaScript.

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

[chrisl99]

JS modules are working in Safari Technology Preview today - so it should be available to everyone soon enough. Pretty simple too, you load your entry point like this -

<script type="module" src="main.js">

And then main.js runs in strict mode, can use "import", etc.

[moron4hire]

Even if the browsers support modules, you still will want to generate a bundle, because loading modules on the fly would require lots of tertiary HTTP requests.

[iainmerrick]

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

I've been wondering the same thing. Surely the only exciting new language features are the ones that can't be polyfilled?

Native support means it can be smaller and faster, sure. But I don't think you can blame web bloat on Javascript's lack of built-in modules. Web bloat is caused by an arms race of advertising and tracking plugins. I don't care much about making those more efficient, I just want the advertising and tracking stripped out.

[Crespyl]

I wouldn't be surprised if a lot of the major players are holding back on JS modules until after WASM gets farther along.

It could seem like a waste of effort to standardize and implement JS modules (which "everyone already has" via transpilers) when they expect people to move quickly to language agnostic WASM modules once they become available.

[dotancohen]

With native support you can debug in a current web browser. Also, native support means that you can ditch the compiler / transpiler earlier.

[z3t4]

es6 modules are basically sugars for async loading (AMD) with some limitatons/restrictions.

[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...) but does anyone know why? Is strict mode something we should now be avoiding?

[bushin]

Nicholas Zakas has a nice explanation

https://leanpub.com/understandinges6/read#leanpub-auto-chang...

[uwu]

my guess: to not complicate parsing complex expressions in default parameters

  // non-strict mode top-level code
  
  function foo (complex = eval("1+1"), moreComplex = (function(){ with (this) { return bar; } }())) {
      
	  "use strict"; // go back and parse the parameters again but this time with strict mode semantics
      
	  // ...
	  
  }

[swhipple]

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

[1] https://www.nczonline.net/blog/2016/10/the-ecmascript-2016-c...

[kozak]

"use strict" has to be outside of the function in this case.

[diggan]

According to the documentation on MDN[0], it's a part of "early errors" and you should rather but the "use strict" outside the function instead of on the inside. I'm not entirely sure of why the spec wants it to be outside rather than inside though...

- [0] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

[TheAceOfHearts]

If you're using a bundler and transpiler, ES modules are already in strict mode.

[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

[whatever_dude]

And yet WebKit has 99% on ES5, while Edge and Firefox have 100% (and Chrome has 98%).

http://kangax.github.io/compat-table/es5/

[pjmlp]

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

[krzyk]

Chrome has 85% in the above table (up from 80% from previous version), so why you are saying 100%?

Maybe the above table doesn't include beta releases of Chrome?

[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!)

[pas]

Well, realistically, if you want an objectively better JS, use TS. It's completely opt-in, transpiles/compiles to JS, and you can finally maintain projects with more than 1 JS file in them, and no longer have to rage-delete the whole scripts.js file when - after adding the 66th god forsaken jQuery lib - something blows up the whole damn thing and all you're left with is a ridiculous error deep from within an unrelated library.

[dandersh]

I think the Array.includes makes the language better as it standardizes how to check for array membership. I've encountered more than one bug as a result of the "!== -1" check not working correctly/as expected.

[dwaltrip]

`Object.entries` and `Object.values` are huge wins in my book. Makes common looping operations less obtuse and obfuscated.

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

[SimeVidas]

Async iteration is already at Stage 3? Nice.