ES modules: A cartoon deep-dive

https://hacks.mozilla.org/2018/03/es-modules-a-cartoon-deep-dive/

by skellertor • 8 years ago

217 28 8 years ago

hacks.mozilla.org

dcwca• 8 years ago

Great work by Lin Clark, as usual!

kopite• 8 years ago

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

mrspeaker• 8 years ago

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

shriek• 8 years ago

I was playing with @std/esm yesterday and it helps bridge that gap somewhat. I agree it feels great to not have to transpile anymore. :)

WorldMaker2• 8 years ago

That module loader was declared "stable" today, even.

https://medium.com/web-on-the-edge/tomorrows-es-modules-toda...

drudru11• 8 years ago

Nice demo!

TheAceOfHearts• 8 years ago

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.

thelarkinn2• 8 years ago

Exactly. Alt-Title: Why we use webpack.

thelarkinn2• 8 years ago

Hi there!!! Sean from the webpack team!

For a development environment this is great. However if there's any takeaway from this post, it is the reminder that all of the resolve, parse, eval, execute, graph traversal, and linking has to be done at runtime, so if you are okay with your app taking 1000x longer to load then if you bundle it, then I guess that's a personal preference.

However, we will continue to endorse for the sake of web performance that you bundle your code, and not use modules natively :-)

EamonnMR• 8 years ago

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.

jimmytidey• 8 years ago

A beautiful explanation.

ballenf• 8 years ago

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.

ivanfon• 8 years ago

MDN has the best articles.

tw1010• 8 years ago

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

plopz• 8 years ago

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.

WorldMaker2• 8 years ago

There are proposals being debated for this. The article mentions specifically this one: https://github.com/domenic/package-name-maps

Touche• 8 years ago

Moving files around is not something you do all that often. Doing so will present a problem in most any programming language.

Sophistifunk• 8 years ago

This is really not true. Moving files around is trivial in anything with a decent type system and IDE.

mnutt• 8 years ago

Ember has a convention to resolve files in its 'app' directory from your project name, and it makes renaming files a lot easier: `import { thing } from 'my-project/thing/in/dir.js'`

danlugo92• 8 years ago

RequireJS has this too.

Can_Not• 8 years ago

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

panopticon• 8 years ago

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

underwater• 8 years ago

Can you also teach systems with their own resolution about the aliases (Jest, Flow, etc.)

iamnotlarry• 8 years ago

I wrote a very small resolve hook for node that does this. It makes the directory of the initial module / for all imports. Node has made resolver hooks like that dead simple.

reaktivo• 8 years ago

You an usually use `NODE_PATH=src` which will make requiring anything inside `src` easy as `import something from 'somewhere';`

incadenza• 8 years ago

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.

jasonkester• 8 years ago

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.

ES modules: A cartoon deep-dive

Related Stories