
ES modules: A cartoon deep-dive - skellertor
https://hacks.mozilla.org/2018/03/es-modules-a-cartoon-deep-dive/
======
mrspeaker
I can't wait for ES module support in Firefox by default (so all major
browsers are covered). It feels so good to be able to write code in "plain old
JavaScript" again without the need for transpilers and build tools for small
apps. I made this minecraft WebGL2 thing
([https://mrspeaker.github.io/webgl2-voxels/](https://mrspeaker.github.io/webgl2-voxels/))
all in modules, and being able to just view-source without any shenanigans
feels like the old days.

The only issue now is I want to share the code with a Node server... I really
hope the new proposals will help bridge the require/import gap!

~~~
TheAceOfHearts
It's great for small apps, demos, and development!

But for deploying it'll probably continue to be a good idea to have build
step. If you need to support a wider range of browser, you'll want a
transpilation step. Minifying can drastically reduce the payload size. If you
want tree shaking, that requires a build tool. Even with HTTP 2.0 and being
able to push stuff down to the client you'll need to crawl the dependency
graph and generate some kind of manifest for the server to know what to send.
You can do those things on the fly, but that's just turning it into an
implicit build step.

Depending on how frequently things are changing, there's also the matter of
simultaneous versions of the app running at same time. If you're loading
modules asynchronously, a user with Version A of the app could end up
importing something meant for Version B. Users sometimes go for weeks or
longer without refreshing a tab. Tools like Webpack make it easy to have all
your module references updated and named correctly to avoid this kind of
clash.

These aren't problems that all apps need to handle. In fact, it's great if you
can get away without any of it! But those kinds of use-cases are what tools
such as Webpack help to solve.

~~~
thelarkinn
Exactly. Alt-Title: Why we use webpack.

------
plopz
The problem I find with the current ES modules is a lot of statements like
this

import {thing} from '../../../thing/in/dir.js'

and then if I move a file I have to change all of its imports to a different
number of parent traversals. It would be really nice to be able to define a
path that all imports would be relative from.

I think babel has something like this using @, but I don't use babel right
now.

~~~
Can_Not
You can set a custom alias, for example nuxt uses ~ for project root. I've
seen projects use @ also.

~~~
panopticon
That's not part of the ES module spec. That's something transpilers (like
Babel + a plugin) support.

------
kopite
Good work Lin. You are the hero, JS community needs.

------
EamonnMR
This has been the only thing keeping me using Babel for a couple of years now.
Every other ES6 thing I really wanted is in vanilla JS. I'm pretty thrilled.

------
ivanfon
MDN has the best articles.

------
tw1010
This is what we get when we encourage rather than actively discourage new
innovative ways to explain things. There are so many academic fields that
could reduce their learning curve if they only embraced this idea rather than
close off any and all attempts to deviate from the path of established
rhetoric (which could cause huge cascades of innovation throughout all
industries, making many fields look a lot more similar in their pace of growth
to the front end world).

------
ballenf
FWIW, I was wanting to play with native modules locally using files loaded
directly in browser instead of a local Node instance.

That's about impossible in Chrome (in my experience and as per SO answers) and
trivially easy in Safari.

Develop menu / Disable Cross-Origin Restrictions

Not that spinning up node is really any slower when you take into account
auto-reload capabilities.

------
jasonkester
It seems like the pendulum of "configuration vs. convention" has swung all the
way back to the configuration side.

Before: add all the scripts you'll need to the HTML. Just don't run any
scripts before the document loads.

Today: bundle in 6mb of dependencies to solve that "problem" so that we don't
have to use window.onload.

I especially like the sibling commment about how this new development gets us
closer to the good old days of being able to view source on our code. As
though that was something that had happened to them, rather than a conscious
decision to adopt worse tools.

------
incadenza
These Mozilla posts are very well done! As per the article, I'm always excited
to see the JS community converge towards decent standards. This has been a
long time coming.

------
dcwca
Great work by Lin Clark, as usual!

------
jimmytidey
A beautiful explanation.

