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

101–110 of 175 posts

Re: ES modules are terrible

#101

Post by Ginden »

cookiengineer wrote: post #77

This thread and summary are written by someone who has no clue what they're doing in ECMAScript; and who's probably enjoying the fucked up mess that the babel ecosystem created. I'm not gonna dig into that, because reading any polyfill in babel's ecosystem speaks for themselves on how messy, hacky, and actually not working-as-specified most parts are. Instead I'm gonna try to go back to the topic. I think that in pra…

> - "export already_imported_variable;" - why the HECK is this not in the specification? Having to declare new variable names for exports makes the creation of "index" files so damn painful. This syntax could fix this.

You can do:

   export {already_imported_variable}

Re: ES modules are terrible

#102

Post by theprotocol »

devmunchies wrote: post #100
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.

I just encountered this. FYI You can use v2 which still retains commonjs support.

Re: ES modules are terrible

#103

Post by catern »

simonw wrote: post #92
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?

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.

Hm, I wonder if this could be circumvented by doing timing attacks against the CDN cache? That's still shared between domains...

Re: ES modules are terrible

#104

Post by andrew_ »

theprotocol wrote: post #102
devmunchies wrote: post #100

Earlier quoted context omitted.

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

I just encountered this. FYI You can use v2 which still retains commonjs support.

I've ended up using last major versions as well. I plan to move to Deno anyhow, and authors like sindresorhus are at least applying security updates to the major version before the switch.

Re: ES modules are terrible

#105

Post by kabes »

andrew_ wrote: post #89
kabes wrote: post #47

Earlier quoted context omitted.

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

That's only valid for dynamic imports. But if we consider dynamic imports half of the rant in the post is wrong, since these can appear nested.

Re: ES modules are terrible

#106

Post by martpie »

TekMol wrote: post #81
incrudible wrote: post #72

Earlier quoted context omitted.

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

That's true if you create your own bundle yourself. Famous frameworks like Next.js or Nuxt make much smarter bundles, with common dependencies grouped together, and bundling the rest by page/view, then loading each bundle when needed.

Re: ES modules are terrible

#107

Post by aurelianito »

Both CommonJS and ES6 modules suck. The way things should have been is requirejs. Modules are defined and loading using an API instead of having reserved words. It's really sad what happened to modules in JavaScript.

Re: ES modules are terrible

#108

Post by lampe3 »

joepie91_ wrote: post #82
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 s…

"Wie man in den Wald hinein ruft, so schallt es heraus" since your from NL it should be easy to translate.

These heavy plugins are usually for old browsers to also run in them. That is the only job ob babel.

CJS has some deeper problems. - Check if your fav CJS lib freezes the objects? - ESM is more http friendly (mime type)

Re: ES modules are terrible

#109

Post by qudat »

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?

We already do this with a build step using a vendor bundle and an app bundle and it can be configured to create a bundle for each page.

Re: ES modules are terrible

#110

Post by spankalee »

This post is terrible, actually.

CommonJS was never going to be natively supported in browsers. The synchronous require semantics are simply incompatible with loading over a network, and the Node team should have known this and apparently (according to members of TC39 at the time) were told their design would not be compatible with future a JS module standard.

So the primary thing that JS modules fix is native support, and for that you need either dedicated syntax or an AMD-style dependencies / module body separation. AMD is far too loose (you could run code outside the module body), so dedicated syntax it is.

Everything else flows from there. I really hate how people blame the standards instead of the root cause which is Node not having taken the browser's requirements into consideration. Culturally, I think that's mostly fixed now, but it was a big problem early on in Node's evolution.

Post reply on HN