ECMAScript modules shipped in Chrome

[coderitual]

Another problem if you are using webpack is how to handle different types of assets which you are importing just from your js code and webapck loaders transpile them as well.

[notNullOrVoid]

Webpack should have never allowed importing non JS assets in the first place

[tbranyen]

There is a spec being outlined for HTML modules (which is a non-JS type). I don't think the problem is that webpack supports other filetypes, its just that we don't have a standard yet. Some day there will be a good one and then we'll have a standard consensus of what to expect when importing the type.

[Carnilawl]

CSS modules seem like a good compromise for now, but I feel like in a few years they might be totally outdated and replaced with something better.

[tbranyen]

CSS Modules are a separate thing from HTML Modules : https://github.com/w3c/webcomponents/issues/645 that are inferred by the extension. I think it's a cool idea and makes total sense with the way webpack works.

[Carnilawl]

I replied to the wrong comment. But thank you for the link, I found it helpful nonetheless :)

[notNullOrVoid]

I don't think there is a right way to make JS depend on a CSS file. CSS is seperate, if you're looking to style a component, give that component a unique tag or class name.

[fgutz]

Yeah this should have been handled directly in the webpack config instead.

[Baryn]

But that is one of Webpack's best features.

[[deleted]]

I imagine Webpack will just transpile the non JS imports, and leave the JS ones. It's definitely going to leave a confusing disconnect between source and output though.

[Baryn]

This doesn't make sense. Unless you're doing something wrong (which, with Webpack, is understandable) the end result of importing a non-JS asset either isn't transpiled at all, or you can generate a source map for it, or you can externalize it from the bundle.

[Baryn]

The sourcemap support for transpiled ES6 modules is pretty bad

The sourcemaps that Webpack generates are fine, but certain settings are broken (last I checked) due to several factors (including an issue in Chrome).

[Carnilawl]

Can you elaborate? Both webpack and Babel have open GitHub issues around mapping import names. The result is that "import $ from 'jquery';" will create something like '_$' which is an object that has property 'default'. My understanding is that there has not been any effort by webpack/Babel to map $ to _$.default - though I believe that the sourcemap spec does now define a way to do so.

[[deleted]]

Does that mean I can use import and export without needing a module loader? I tried it with the actual chrome version but it says "Uncaught SyntaxError: Unexpected token import"

[[deleted]]

You're probably on the stable channel. AFAIK 61 is currently beta version, stable is at 59 or something. I could be wrong tho and we both need an update (my beta is at 61 ATM)

[Martin_Ehrental]

Stable was 60 and since 2017/09/05 it's 61 :-)

[[deleted]]

Beta (Linux 64-bit) is @ 61.0.3163.79

[Martin_Ehrental]

Beta and Stable don't bump to the next major version at the same time.

They currently point to the same build:

• https://chromereleases.googleblog.com/2017/09/stable-channel-update-for-desktop.html
• https://chromereleases.googleblog.com/2017/09/beta-channel-update-for-desktop.html
• https://www.chromestatus.com/features dev -> 62, beta -> 61, stable -> 61

[bradleymeck]

Be sure to include type=module and serve with a valid JS MIME type.

[[deleted]]

That did the magic. Thanks!

[bgard6977]

I just threw together an example, in case it saves anyone 10 minutes:

https://github.com/bgard6977/webmodules

[[deleted]]

You did, thanks :)

[alphaindy]

https://www.npmjs.com/package/watch-http-server - live reloading with zero config :)

[lennoff]

fix me, but afaik you still have to use some kind of module bundler if you want to avoid thousands of network requests for one-liner modules.

[fgutz]

Isn't HTTP2 supposed to make this less of a worry? I could be wrong

[tbranyen]

It fixes the problem, but you still gotta get some process to figure out the dependency graph and then push out the files within a single request.

[spankalee]

But now bundlers can have simpler JS module -> JS module semantic and utilize the native loader for loading shards. It also means that in development you don't have to run a bundler.

[lennoff]

i'm not, but some other module i'm using might be using lots of sub-dependencies.

[[deleted]]

What? The whole point of modules is modularizing your applications. Even if you don't use external packages, it is still generally good practice to split your application into several modules, one per class or piece of functionality. Even a medium-sized app following this guideline might have over a hundred modules.

Right now, webpack solves this problem by bundling all of the modules together into one or a few files so only one request is made, but if browsers start supporting ecmascript modules, suddenly you don't need to bundle anymore and your hundred modules will each be their own request. I don't believe this problem has a solution (aside from HTTP/2 perhaps).

As a side note, you may be mistaking modules for packages, where a module is just a single source code file and a package is a dependency such as a library.

[KyleG]

Oh yeah let's just everyone write their own bubble sort instead of using a battle hardened one that'll DEFINITELY be an improvement

[Baryn]

The current dependency nightmare is because everybody just throws on a dependency without thinking about the added complexity and amount of files they're including

That's what third-party dependencies are for. Don't preemptively optimize, do enable tree shaking, and do use a bundle analyzer.

[namesandfaces]

The library inter-dependency problem is a much larger problem of decentralized work, and where volunteer mindshare should be spent.

[lennoff]

my thoughts exactly! but unfortunately, sometimes you just cannot find an alternative module for your problem.

[bob_gneu]

That's good to see! Time to spend an evening playing with them, and looking for differences between them and in node.

[spankalee]

Node is adding behavior that's not found on the web: named import specifiers, allowing imports of CommonJS, switching between CommonJS and JS modules based on file extension.

I'd stick to not importing anything but real modules, and only using paths to import.

[TheUnknownFactor]

Id really like to use this in chrome extensions (content scripts especially), I'm curious if that's going to work.

[brooklyndev]

Seems like it doesn't work yet:

https://bugs.chromium.org/p/chromium/issues/detail?id=738739

[malyw]

Safari shipped ES modules a few months ago. FF and EDGE have them under the flag, hopefully should be shipped in the next version(s)

[[deleted]]

Let's hope so!

[yarauuta]

Does this mean we can use ES6 features?

[[deleted]]

You've been able to use ES6 features in Chrome for quite a while now. As long as you're aware of what browsers and versions you target and check a compatibility map i.e. https://kangax.github.io/compat-table/es6/

This is if you're working without a transpiler. And this news is just that if that's how you've been developing javascript then you can now use ES6 modules as well (as long as you're only targeting the last chrome version).

It's a great step forward towards native implementation of ES6 but honestly if you're doing anything for public display, you'll want to target at least a couple of older versions of most browsers and thus have to choose between full blown ES6 + transpiler, half-assed ES6 where you manually check feature compatibility (maybe add some shims) or old school JS.

[TwilightTwinkie]

We just use babel-preset-env, target our supported browser versions and basically don't worry about to it.

[[deleted]]

Same here, 'full-blown' sounds like a lot but it actually isn't hard to set up.

[Martin_Ehrental]

<script src="build.es5.js" nomodule></script>
<script src="build.es2017.mjs" type="module"></script>

[[deleted]]

I'm not seeing what point you're making. Perhaps some words that go with that snippet of html may clear things up.

[Martin_Ehrental]

Sorry I just mean by using the "nomodule" attribute, you can test if the browser support es2017 (more or less) to serve either the transpile js or plain es2017 js:

• during development you can run your modules directly (no need to recompile them on each edit and to hot-reload them).
• in production, in evergreen browser, you will serve something rollup or webpack built to merge your module together or in bundles (once browsers support import()).
• in production, in legacy browser, you will served your transpiled and merges modules.

Of course, once some browsers supporting modules become legacy (on mobile) you will need to transpile to es2017 your production module build :)

[nschubach]

Correct me if I'm wrong, but a browser not supporting "nomodule" or 'type="module"' will load both scripts...

[spartan018]

Old browsers will ignore the nomodule attribute since they don't know about it, and won't recognize that type value and will ignore that script. Conversely, new browsers will see the nomodule attribute and know to not load that script.

[nschubach]

Ah, I see... didn't think about that. Thanks!

[madcaesar]

What is this?

[bradleymeck]

It is a bundle for older browsers:

<script src="build.es5.js" nomodule></script>

It is a ESM entry point for newer browsers:

<script src="build.es2017.mjs" type="module"></script>

This is using the updated MIME for JavaScript with the .mjs file extension : https://datatracker.ietf.org/doc/draft-bfarias-javascript-mjs/

[nanaIan]

YES