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

ES modules are terrible

gist.github.com

Post reply on HN
Print view View original

81–90 of 175 posts

Re: ES modules are terrible

#81

Post by TekMol »

incrudible wrote: post #72
TekMol wrote: post #46

ES Modules are great. Building JS applications is so much speedier, leaner and more fun now that they are supported widely. One fallacy the author falls for is that they think one needs a build step "anyway" because otherwise there would be too many requests to the backend. Loading an AirBnB listing causes 250 requests and loads 10MB of data. With a leaner approach, using ES Modules, the same functionality can be don…

> Loading an AirBnB listing causes 250 requests and loads 10MB of data. How many of these requests are dependent? Lazily loading hundreds of images doesn't impact page responsiveness, but loading an import of an import of an import before your page does anything is unacceptable. > I use ES Modules for all my front end development and I get nothing but praise for how snappy my web applications are compared to the comp…

    tell me that doesn't improve load times
It will negatively impact load times.

Either you only bundle what is needed on the current page. Then the next page will load slower because it needs to bundle all those modules again as it uses a slightly different set of modules.

Or you bundle everything used on any page your users might go to during their session. This will give you a giant blob that has to be loaded upfront which contains a ton of modules the user never need during their browsing session.

Re: ES modules are terrible

#82

Post by joepie91_ »

lampe3 wrote: post #57

Not sure it the author tried a new build tool like vite, esbuild and so on. Working on large projects and having everything first loaded and then you can load it in the browser is a waste of time that every web developer has every day. Some real world times FOR DEVELOPMENT: Storybook first load: 90 sec, Storybook after first load changes: 3 sec, Vue App first load: 63 sec, Vue app change after that: 5 sec, Vue App wi…

Hi, author here. I'm going to ignore the personal attacks and simply point out that my dev build processes typically have a startup time of under 5 seconds even for large projects, and a rebuild time of under 500ms. This is with Browserify.

If you are having very slow build times with your existing toolchain, the problem isn't the bundling, which is an extremely fast operation. It's almost certainly going to be one specific computationally-intensive plugin that you either don't need, or would also need if using ESM.

Re: ES modules are terrible

#83

Post by joepie91_ »

bricss wrote: post #8

First you create problem with an article, then you fix it with your own magic tool, bravo! https://www.npmjs.com/package/fix-esm

Believe me, I would much rather not have had to build that hack. But considering that I want my development tools to actually, y'know, work, what would you expect me to do?

Re: ES modules are terrible

#84

Post by joepie91_ »

e1g wrote: post #51
somehnacct3757 wrote: post #36

I keep thinking how QUIC / HTTP/3 would go nicely with ESM in the browser (via script tags with type=module) for simple sites. A webmaster could totally avoid the complexity of learning a JS tool chain. Right now even 1000 lines of JS has you reaching for a bundler. It would make shipping a small html+css+js site again as simple as dragging files to your webserver.

Bundling will not go away as it solves a different problem of how to best distribute the app to final users. When authoring code, you want to have many small files so you can keep related logic blocks isolated from the rest. When distributing the code, you want to ship a few larger files to reduce network overheads. Any non-trivial frontend app will call code from 100+ files, and your browser is tuned to request thes…

Worse, even if they were all fetched in parallel, you would still see terrible loading times simply because a dependency graph can only be traversed depth-wise serially. Doesn't matter what network protocol you use or how parallel it is.

Re: ES modules are terrible

#85

Post by unilynx »

somehnacct3757 wrote: post #36

I keep thinking how QUIC / HTTP/3 would go nicely with ESM in the browser (via script tags with type=module) for simple sites. A webmaster could totally avoid the complexity of learning a JS tool chain. Right now even 1000 lines of JS has you reaching for a bundler. It would make shipping a small html+css+js site again as simple as dragging files to your webserver.

QUIC / HTTP3 does not fix the roundtrip wait times caused by dependencies - if 'a.mjs' imports 'b.mjs' which in turn imports 'c.mjs'... you still need two roundtrips to load all three.

only a bundler can fix that (or a hypothetical process which would set up preloads for all required libraries, but that would just be a bundler without the actual bundle creation step)

Re: ES modules are terrible

#86

Post by jitl »

The things I dislike the most in software development is dogma, holy wars, and religious crusades about technology practices. I’m not sure to the extent that this happens in other ecosystems, but it seems to happen quite a bit in JavaScript circles. You can ignore these for the most part if you use boring tools and don’t chase the new frameworks-du-jour, but in the case of ESM versus CommonJS I am starting to feel the fire of this war in my dependency graph.

My solution in NodeJS programs for now is to use an `esbuild` -based require hook to transpile all the files we import or require into CommonJS on the fly. We need esbuild anyways to run Typescript code without a build step, and combined with basic mtime based caching, it’s fast enough that you really don’t notice extra build latency especially on a second run — much MUCH faster than a Babel require hook.

I plan to tune back into this issue once the average comment is more measured and thoughtful, and the ecosystem tooling for dealing with the migration has evolved more.

Re: ES modules are terrible

#87

Post by joepie91_ »

Ginden wrote: post #31
addicted wrote: post #26

Earlier quoted context omitted.

Let’s flip this. What are the advantages of ESM that led to selecting that over CJS modules for standardization in the first place?

Statically analyzable tree. In CJS you have to depend on people not doing strange things to their `module.exports` and you are left with heuristics.

This is not actually a meaningful benefit that ESM has in practice, as I've explained in my article.

Re: ES modules are terrible

#88

Post by andrew_ »

I really, really loathe how major packages in the ecosystem are "We're ESM now, deal with it, sorry about your luck," and forcing the issue. It's arrogant as hell. A hard fork of Node for ESM would have been a much better path (e.g. Deno) That said, the OP's rant is more emotion than fact.

> And then there's Rollup, which apparently requires ESM to be used, at least to get things like treeshaking. Which then makes people believe that treeshaking is not possible with CommonJS modules. Well, it is - Rollup just chose not to support it.

Rollup was created specifically for ESM. It's not been thrust onto the ecosystem or into anyone's tool chain. One uses it specifically for ESM, and plugins that bolt on for added functionality if they apply. Trying to hammer a nail with a paintbrush doesn't make the paintbrush a bad thing - you just chose the wrong tool.

Re: ES modules are terrible

#89

Post by andrew_ »

kabes wrote: post #47
xg15 wrote: post #14

> And then people go "well you can statically analyze it better!", apparently not realizing that ESM doesn't actually change any of the JS semantics other than the import/export syntax, and that the import/export statements are equally analyzable as top-level require/module.exports. ... "But in CommonJS you can use those elsewhere too, and that breaks static analyzers!", I hear you say. Well, yes, absolutely. But tha…

It's not the fact that imports are top level that makes it statically analyzable. It's the fact that the imports can't be variables like commonjs allows.

Say what now?

  const batman = await import('batcave' + version);

Re: ES modules are terrible

#90

Post by tolmasky »

kabes wrote: post #47
xg15 wrote: post #14

> And then people go "well you can statically analyze it better!", apparently not realizing that ESM doesn't actually change any of the JS semantics other than the import/export syntax, and that the import/export statements are equally analyzable as top-level require/module.exports. ... "But in CommonJS you can use those elsewhere too, and that breaks static analyzers!", I hear you say. Well, yes, absolutely. But tha…

It's not the fact that imports are top level that makes it statically analyzable. It's the fact that the imports can't be variables like commonjs allows.

But they can. I can construct any hard to find use case just as easily with import. Your analyzer probably won't find this: "(a => a)(path => import(path))(ROOT_PATH + "/x.js")".

"But no one would do that!" Yeah, and no one does it with require either. The times people pass in variables to require are well warranted and usually not in a browser context (listed this in my other post, but for example loading "x-mac.js" vs. "x-windows.js" in node, where there is no problem since you're not bundling).

So neither in the practical sense nor the hypthetical sense has the "static analysis problem" been solved any more than it was already solved with require. People used require basically like a static keyword before and you could basically make the same usage assumptions as import in those cases. Similarly, you can get as dynamic as require with import, so in the purely theoretical sense not much has been made better either.

Post reply on HN