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

91–100 of 175 posts

Re: ES modules are terrible

#91

Post by forty »

kevingadd wrote: post #79
forty wrote: post #73

Earlier quoted context omitted.

In practice I think downloading many small files is actually slower than a single bigger file. It might not be so true today with http2 for example though.

Yes, it's much slower pre-http2 since no modern browser actually does pipelining, so it's going to be a socket per file HTTP2 fixes this by allowing multiple requests to occur in parallel on a single connection.

In the specific case of JS import, it's still going to be pretty bad though, I guess, since you have to download a file, parse it to figure out the deps, then fetch them, parse them, etc, so you are limited in what you can do in parallel.

Re: ES modules are terrible

#92

Post by simonw »

catern wrote: post #65
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…

>And then - because not bundled - all the modules that will be used on another page will be cached already. Why isn't anyone else mentioning this feature? I'm not a browser developer but this seems like a clear win, and indeed makes bundling unnecessary. I'm assuming that it's shared between domains, too - or are people's dependencies so fragmented that there's basically no sharing between domains?

I believe sharing cached code between domains has been almost entirely eliminated by browsers now, because it turned out to be a huge privacy leak: a malicious domain could attempt to load code that was used by another domain, time how long it took to load and use that to determine if the user had visited that other site.

Browsers fixed this by making the browser cache no longer shared between domains.

Re: ES modules are terrible

#93

Post by tofflos »

catern wrote: post #65
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…

>And then - because not bundled - all the modules that will be used on another page will be cached already. Why isn't anyone else mentioning this feature? I'm not a browser developer but this seems like a clear win, and indeed makes bundling unnecessary. I'm assuming that it's shared between domains, too - or are people's dependencies so fragmented that there's basically no sharing between domains?

The cache used to be shared between domains but that's no longer the case due to privacy concerns and limited effectiveness.

> As of Firefox v85 and Chrome v86 the browser cache will be partitioned, this means that the same resource included on two sites will have to be downloaded from the internet twice and cached separately.

Source https://www.peakhour.io/blog/cache-partitioning-firefox-chro....

Re: ES modules are terrible

#94

Post by andrew_ »

forty wrote: post #54

I have been doing nodejs backend development for the past 10 years and I have no idea why ES module are needed and who is using them. I assume this is a front end thing. We are using typescript which is using "import" syntax, but as far as I know, it's still transpiling to good old "require".

You can tell TS to output ESM. Try using top-level await with TS and you'll run into that. The configuration options are vast.

Re: ES modules are terrible

#95

Post by tentacleuno »

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…

> Yes, dynamic imports exist but they are sort of an exotic feature that you would only use in special situations.

I wouldn't necessarily describe dynamic imports as an exotic feature. They are basically required if you're building a semi-large app (and heavily advised by most frameworks in that case!). Otherwise, your homepage is going to load in some complicated AuthorPage / HeavyComponentWithLotsOfDependencies component the user might not even want.

The main advantage of ESM in this context would be its asynchrony, which you won't get with require. Webpack tried to tack this on with require.ensure, but it was nonstandard and eventually deprecated.

Another advantage of ESM in general would be that you wouldn't have to use preprocessors and compilers like Webpack. My main reasoning here is that, prior to the import spec, web didn't have any form of imports aside from loading in scripts and polluting the global namespace (which isn't necessarily bad). The majority of websites IME use some sort of bundler though, so this isn't really a major change so much as a nice to have, I suppose?

Re: ES modules are terrible

#96

Post by acdha »

tofflos wrote: post #93
catern wrote: post #65

Earlier quoted context omitted.

>And then - because not bundled - all the modules that will be used on another page will be cached already. Why isn't anyone else mentioning this feature? I'm not a browser developer but this seems like a clear win, and indeed makes bundling unnecessary. I'm assuming that it's shared between domains, too - or are people's dependencies so fragmented that there's basically no sharing between domains?

The cache used to be shared between domains but that's no longer the case due to privacy concerns and limited effectiveness. > As of Firefox v85 and Chrome v86 the browser cache will be partitioned, this means that the same resource included on two sites will have to be downloaded from the internet twice and cached separately. Source https://www.peakhour.io/blog/cache-partitioning-firefox-chro... .

This still helps other requests to the same origin, which is a very common situation if you don’t have the extra resources needed to get an SPA up to the same performance and reliability levels.

Re: ES modules are terrible

#97

Post by [deleted] »

forty wrote: post #68
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…

I think the trick is mostly not to have a shitload of dependencies. If you have to load a bunch of huge frameworks, whether it's bundled or you have to download thousands of files one by one, it's going to be slower than not doing it at all :)

[deleted]

Re: ES modules are terrible

#98

Post by acdha »

forty wrote: post #73
catern wrote: post #65

Earlier quoted context omitted.

>And then - because not bundled - all the modules that will be used on another page will be cached already. Why isn't anyone else mentioning this feature? I'm not a browser developer but this seems like a clear win, and indeed makes bundling unnecessary. I'm assuming that it's shared between domains, too - or are people's dependencies so fragmented that there's basically no sharing between domains?

In practice I think downloading many small files is actually slower than a single bigger file. It might not be so true today with http2 for example though.

HTTP/2 definitely changed that and is near-universally supported now. The biggest win is the ability to cache things independently: with bundles your servers and clients have to retransfer everything if a single byte changes, and most of the sites I’ve worked on don’t change most of their files every time they ship an update. A cold visit will usually be immeasurably different from a bundle but a warm visit is noticeably faster.

Re: ES modules are terrible

#99

Post by api »

It’s puzzling to me why there isn’t more effort on developing front end Go or Rust frameworks that compile to JS or WASM. It would be a chance to work in a real language instead of this trash.

Re: ES modules are terrible

#100

Post by devmunchies »

andrew_ wrote: post #88

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

> loathe how major packages in the ecosystem are "We're ESM now, deal with it, sorry about your luck," and forcing the issue

I wasn’t able to use the latest version of node-fetch in a node.js script since it doesn’t support commonjs. The project literally has “node” in the name and doesn’t support default node.js.

Post reply on HN