5 ms·

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

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?

pjmlp 10y ago
> 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.
- dualogy 10y ago
  You mean "the day WebAssembly gets out of preview/alpha/worse status in all major browsers".. yeah, don't we all --- wouldn't hold my breath. Once there, give it another 2 years to actually mature in the wild.
  - pjmlp 10y ago
    I agree, after all we still have some customers on IE 8, but one can wish for it.
moron4hire 10y ago
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.
- shadowmint 10y ago
  I was under the impression HTTP/2 would make this concern irrelevant... but I'm no expert on the subject. I suppose its a valid point. I just don't see what the point in having support for additional js language features natively is if you're forced to use a tranpiler regardless. If you supported only, say, 50% of ES2016, and modules you could plausibly deliver unbundled native ES6; it'd be pretty cool; but modules aren't just a random feature from the pot; there is literally no serious modern web application that doesn't use them. So... I'm struggling to see the ES2016 feature complete map (without modules) as really meaningful for anyone, practically.
  - vmasto 10y ago
    HTTP/2 won't make a serious difference in regards to that, bundling will always be required. Also minifying will always be required, so there's always going to be a build step anyway.
    - jakub_g 10y ago
      Minifying yes but why bundling? https://hpbn.co/http2/#request-and-response-multiplexing https://hpbn.co/http2/#request-and-response-multiplexing HTTP2 takes care of loading files via multiplexing, and ES6 modules take care of loading JS in proper order, no need to bundle AFAIU.
      - vmasto 10y ago
        Sorry for the late reply. Multiplexing is not a panacea, there's still some overhead, and even if there wasn't there's still a point where you start to lose lot of performance by limiting gzip compression (the smaller the file the less efficient the compression is). You can read more about why we'll always need a bundling step at the following links: http://engineering.khanacademy.org/posts/js-packaging-http2.htm http://engineering.khanacademy.org/posts/js-packaging-http2.... https://medium.com/@asyncmax/the-right-way-to-bundle-your-assets-for-faster-sites-over-http-2-437c37efe3ff#.sjb5wen8t https://medium.com/@asyncmax/the-right-way-to-bundle-your-as... https://medium.com/webpack/webpack-http-2-7083ec3f3ce6#.74q6ro5kl https://medium.com/webpack/webpack-http-2-7083ec3f3ce6#.74q6...
evilpie 10y ago
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 https://bugzilla.mozilla.org/show_bug.cgi?id=568953) to fix before we can ship this.
- mrspeaker 10y ago
  What does that flag actually enable? I can't seem to get it to load any modules (even with type="module") - there hasn't been any movement on that bug for a while, and the last comment says "looks like it is only supported for chrome documents"... I know I'm just being impatient, but I'd love to ditch Babel for my own projects and this is my last "must have" ;)
  - bzbarsky 10y ago
    It was only supported for chrome documents until https://bugzilla.mozilla.org/show_bug.cgi?id=1330657 https://bugzilla.mozilla.org/show_bug.cgi?id=1330657 landed in Firefox Nightly two weeks ago. So if you have a current nightly and set the "dom.moduleScripts.enabled" preference to true in about:config, <script type="module"> should work.
hzoo 10y ago
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-es2015-and-beyond.html https://v8project.blogspot.com/2017/02/high-performance-es20... I made https://github.com/babel/babel-preset-env 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.
- mstade 10y ago
  Thanks for your excellent efforts hzoo, and of course everyone else involved! The new env preset really makes it much easier to maintain a forward looking code base.
  - hzoo 10y ago
    Thanks! Will be working torward making the preset-env + babel-minify combo work much better soon.
dotancohen 10y ago
With native support you can debug in a current web browser. Also, native support means that you can ditch the compiler / transpiler earlier.
Crespyl 10y ago
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.
JoshGlazebrook 10y ago
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-modules-in-node-js-42c958b890c#.afjuek8br https://medium.com/the-node-js-collection/an-update-on-es6-m...
- mstade 10y ago
  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.
- NegativeLatency 10y ago
  Oh goodie another file extension.
mstade 10y ago
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.
- Bahamut 10y ago
  From what I have been told, this proposal is likely to win out: https://github.com/tc39/proposal-dynamic-import https://github.com/tc39/proposal-dynamic-import
  - mstade 10y ago
    Looks to be a stage 3 proposal[1] so that seems likely. Had a quick read through, looks like a pretty solid proposal. If I read it correctly, it means `import()` will only load ES2015 modules. (I.e. the result of HostResolveImportedModule is a Module Record. That's a good thing as far as I'm concerned. Given the history of discussion around this, this seems surprisingly low key and reasonable. (The System.loader stuff was gnarly!) But what does this mean for nodejs? I don't see how this rhymes with current proposals re `require.import` and the likes. If the above proposal wins out it becomes a language spec, so presumably will also become available in nodejs, and if they go ahead with the ideas mentioned in another comment here, we'd have both `import(specifier)` and `require.import(specifier)` – seems pretty confusing, but maybe I'm getting it all wrong? [1]: https://github.com/tc39/proposals https://github.com/tc39/proposals
chrisl99 10y ago
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.
iainmerrick 10y ago
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.
- nicoburns 10y ago
  Native async functions are nice for the better debugging support (chrome will give you full stack traces that are as nice as ones from synchronous code).
z3t4 10y ago
es6 modules are basically sugars for async loading (AMD) with some limitatons/restrictions.

pjmlp 10y ago

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

dualogy 10y ago
You mean "the day WebAssembly gets out of preview/alpha/worse status in all major browsers".. yeah, don't we all --- wouldn't hold my breath. Once there, give it another 2 years to actually mature in the wild.
- pjmlp 10y ago
  I agree, after all we still have some customers on IE 8, but one can wish for it.

moron4hire 10y ago

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.

shadowmint 10y ago
I was under the impression HTTP/2 would make this concern irrelevant... but I'm no expert on the subject. I suppose its a valid point. I just don't see what the point in having support for additional js language features natively is if you're forced to use a tranpiler regardless. If you supported only, say, 50% of ES2016, and modules you could plausibly deliver unbundled native ES6; it'd be pretty cool; but modules aren't just a random feature from the pot; there is literally no serious modern web application that doesn't use them. So... I'm struggling to see the ES2016 feature complete map (without modules) as really meaningful for anyone, practically.
- vmasto 10y ago
  HTTP/2 won't make a serious difference in regards to that, bundling will always be required. Also minifying will always be required, so there's always going to be a build step anyway.
  - jakub_g 10y ago
    Minifying yes but why bundling? https://hpbn.co/http2/#request-and-response-multiplexing https://hpbn.co/http2/#request-and-response-multiplexing HTTP2 takes care of loading files via multiplexing, and ES6 modules take care of loading JS in proper order, no need to bundle AFAIU.
    - vmasto 10y ago
      Sorry for the late reply. Multiplexing is not a panacea, there's still some overhead, and even if there wasn't there's still a point where you start to lose lot of performance by limiting gzip compression (the smaller the file the less efficient the compression is). You can read more about why we'll always need a bundling step at the following links: http://engineering.khanacademy.org/posts/js-packaging-http2.htm http://engineering.khanacademy.org/posts/js-packaging-http2.... https://medium.com/@asyncmax/the-right-way-to-bundle-your-assets-for-faster-sites-over-http-2-437c37efe3ff#.sjb5wen8t https://medium.com/@asyncmax/the-right-way-to-bundle-your-as... https://medium.com/webpack/webpack-http-2-7083ec3f3ce6#.74q6ro5kl https://medium.com/webpack/webpack-http-2-7083ec3f3ce6#.74q6...

evilpie 10y ago

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 https://bugzilla.mozilla.org/show_bug.cgi?id=568953) to fix before we can ship this.

mrspeaker 10y ago
What does that flag actually enable? I can't seem to get it to load any modules (even with type="module") - there hasn't been any movement on that bug for a while, and the last comment says "looks like it is only supported for chrome documents"... I know I'm just being impatient, but I'd love to ditch Babel for my own projects and this is my last "must have" ;)
- bzbarsky 10y ago
  It was only supported for chrome documents until https://bugzilla.mozilla.org/show_bug.cgi?id=1330657 https://bugzilla.mozilla.org/show_bug.cgi?id=1330657 landed in Firefox Nightly two weeks ago. So if you have a current nightly and set the "dom.moduleScripts.enabled" preference to true in about:config, <script type="module"> should work.

hzoo 10y ago

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-es2015-and-beyond.html https://v8project.blogspot.com/2017/02/high-performance-es20... I made https://github.com/babel/babel-preset-env 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.

mstade 10y ago
Thanks for your excellent efforts hzoo, and of course everyone else involved! The new env preset really makes it much easier to maintain a forward looking code base.
- hzoo 10y ago
  Thanks! Will be working torward making the preset-env + babel-minify combo work much better soon.

dotancohen 10y ago

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

Crespyl 10y ago

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.

JoshGlazebrook 10y ago

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-modules-in-node-js-42c958b890c#.afjuek8br https://medium.com/the-node-js-collection/an-update-on-es6-m...

mstade 10y ago
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.
NegativeLatency 10y ago
Oh goodie another file extension.

mstade 10y ago

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.

Bahamut 10y ago
From what I have been told, this proposal is likely to win out: https://github.com/tc39/proposal-dynamic-import https://github.com/tc39/proposal-dynamic-import
- mstade 10y ago
  Looks to be a stage 3 proposal[1] so that seems likely. Had a quick read through, looks like a pretty solid proposal. If I read it correctly, it means `import()` will only load ES2015 modules. (I.e. the result of HostResolveImportedModule is a Module Record. That's a good thing as far as I'm concerned. Given the history of discussion around this, this seems surprisingly low key and reasonable. (The System.loader stuff was gnarly!) But what does this mean for nodejs? I don't see how this rhymes with current proposals re `require.import` and the likes. If the above proposal wins out it becomes a language spec, so presumably will also become available in nodejs, and if they go ahead with the ideas mentioned in another comment here, we'd have both `import(specifier)` and `require.import(specifier)` – seems pretty confusing, but maybe I'm getting it all wrong? [1]: https://github.com/tc39/proposals https://github.com/tc39/proposals

chrisl99 10y ago

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.

iainmerrick 10y ago

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.

nicoburns 10y ago
Native async functions are nice for the better debugging support (chrome will give you full stack traces that are as nice as ones from synchronous code).

z3t4 10y ago

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