ES modules: A cartoon deep-dive(hacks.mozilla.org)

217 pointsby skellertor8 tahun yang lalu28 comments

hacks.mozilla.org

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

29 comments

mrspeaker8 tahun yang lalu

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!

TheAceOfHearts8 tahun yang lalu

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.

thelarkinn8 tahun yang lalu

Exactly. Alt-Title: Why we use webpack.

shriek8 tahun yang lalu

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

WorldMaker8 tahun yang lalu

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

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

52-6F-628 tahun yang lalu

Wow! That's great! Thanks for linking this

thelarkinn8 tahun yang lalu

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

drudru118 tahun yang lalu

Nice demo!

plopz8 tahun yang lalu

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.

WorldMaker8 tahun yang lalu

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

mnutt8 tahun yang lalu

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'`

danlugo928 tahun yang lalu

RequireJS has this too.

Touche8 tahun yang lalu

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

Sophistifunk8 tahun yang lalu

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

iamnotlarry8 tahun yang lalu

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.

reaktivo8 tahun yang lalu

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

Can_Not8 tahun yang lalu

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

panopticon8 tahun yang lalu

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

underwater8 tahun yang lalu

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

kopite8 tahun yang lalu

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

EamonnMR8 tahun yang lalu

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.

ivanfon8 tahun yang lalu

MDN has the best articles.

tw10108 tahun yang lalu

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

ballenf8 tahun yang lalu

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.

jasonkester8 tahun yang lalu

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.

incadenza8 tahun yang lalu

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.

[deleted]8 tahun yang lalu

dcwca8 tahun yang lalu

Great work by Lin Clark, as usual!

jimmytidey8 tahun yang lalu

A beautiful explanation.