Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

ES modules: A cartoon deep-dive

hacks.mozilla.org

Post reply on HN
Print view View original

21–30 of 30 posts

Re: ES modules: A cartoon deep-dive

#21

Post by TheAceOfHearts »

mrspeaker wrote: post #4

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 o…

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.

Re: ES modules: A cartoon deep-dive

#22

Post by panopticon »

Can_Not wrote: post #18
plopz wrote: post #14

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.

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

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

Re: ES modules: A cartoon deep-dive

#23

Post by danlugo92 »

mnutt wrote: post #17
plopz wrote: post #14

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.

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

RequireJS has this too.

Re: ES modules: A cartoon deep-dive

#24

Post by iamnotlarry »

plopz wrote: post #14

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.

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.

Re: ES modules: A cartoon deep-dive

#25

Post by thelarkinn »

mrspeaker wrote: post #4

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 o…

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

Re: ES modules: A cartoon deep-dive

#26

Post by thelarkinn »

TheAceOfHearts wrote: post #21
mrspeaker wrote: post #4

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 o…

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 dependenc…

Exactly. Alt-Title: Why we use webpack.

Re: ES modules: A cartoon deep-dive

#28

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

Re: ES modules: A cartoon deep-dive

#29

Post by underwater »

Can_Not wrote: post #18
plopz wrote: post #14

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.

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

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

Re: ES modules: A cartoon deep-dive

#30

Post by reaktivo »

plopz wrote: post #14

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.

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