Welcome to JavaScript, where everything's made up and the points don't matter.
ES modules are terrible
161–170 of 175 posts
Re: ES modules are terrible
#162Earlier quoted context omitted.
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.
It’s still a tradeoff, though. Let’s say a website has three pages: /a, /b and /c. Two of those pages, /a and /b, each use the module `foo`. Where should `foo` get bundled? If you put it in the “common” bundle, it’ll get served to /c even though it’s not needed. If you put it in both of the bundles for /a and /b, the client will download it twice.
Most bundlers:
- have more sophisticated dependency tracking and will split a separate chunk for a/b
- can produce some kind of a manifest to allow you to preload and avoid nested waterfalls
- provide some mechanism for greater control over what gets chunked separately or combined, for the usage/caching scenarios you’ll undoubtedly know better than a general purpose program
Re: ES modules are terrible
#163Earlier quoted context omitted.
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.
That’s what `modulepreload` &co is for. It’s a shame HTTP Push is dead, it was a much more general solution. But specifically for web pages the solution is more or less the same + 1 round trip (you won’t get the benefits of “push” until you at least process all the head>meta tags).
Re: ES modules are terrible
#164ES 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 :)
It depends on your bundler and config. You might have “zero” dependencies, but depending on how the code is split you might end up with thousands of small imports nested quite deeply.
Re: ES modules are terrible
#165> for some completely unclear reason, ESM proponents decided to remove that property. There's just no way anymore to directly combine an import statement with some other JS syntax This is one of those 'worse is better' things in language design, I believe. It guarantees simplicity, traded off against extra verbosity. In fact, when it comes to the common and probably most valuable case of reading and understanding cod…
I would have considered this a valid argument if overly-clever use of `require` was actually a problem in JS. But it's not! These 'simple' types of obvious cases are the only types of cases that people actually use this syntax for in practice.
I have seen horrors of abuse of the CJS require cache, I’m glad to hear you haven’t had to deal with it.
For what it’s worth, whether it’s bitten you or not, every single instance of my sillycode[1] is in use in Jest (granted in obviously more useful ways). And it’s an enormous headache to debug when it goes wrong. A trivial example: require a logging library which creates a singleton at module definition time and provides no teardown API (yeah that sounds like a bad design but believe me they exist, are easy to find, and hard to replace on a busy and/or opinionated team). If you have a single suite with 100 tests, Jest will leave 100 instances of that singleton running and consuming memory even while totally idle, completely inaccessible to most any machination you might come up with to try to free them.
Which isn’t to say ESM doesn’t have this same problem if you try to bust the import cache with eg query parameters. But at least you’ll probably notice it’s a problem because you’re very probably doing it directly and not with some opaque Babel transform that hijacks the entire module system and any code referencing it.
1: https://news.ycombinator.com/item?id=29140847
Edit: forgot which sub thread I was in, added link to my sillycode
Re: ES modules are terrible
#166This 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 suppor…
But it doesn't matter for Node, since async ESM is a superset of sync CommonJS. Simply putting await before every ESM import gives the Node semantics.
So, isn't adding ESM to Node is strictly a new feature? What am I missing?
Re: ES modules are terrible
#167ES 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 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 competition.
Word up. Share a link? I feel like the pro-ESM crowd shoudl stick together!
Re: ES modules are terrible
#168question: // ... if (condition) { const x = require('../../../hugeFuckingLibraryThatTakesSeveralSecondsToLoadUponColdStart') // do something with x } // ... assume I don't give a fuck about nerd bullshit and I just want the code to be simple and the program to run fast (which it does when !condition because it doesn't need to load hugeFuckingLibrary), can I replicate this behavior with ESM?
Well since you asked so "fuckin" nicely /s if( condition ){ import('../../../hugeFuckingLibraryThatTakesSeveralSecondsToLoadUponColdStart').then( x => { //do something with x }) } > ...nerd bullshit... I hate to break it to you darling, but programming is nerd bullshit. edit: alternate that might too much "nerd bullshit", but uses async/await if the surrounding code is an async function: async function doSomeStuff()…
no bro, programming is programming and nerd bullshit is nerd bullshit. the arguments I see in favor of ESM over CJS fall into the latter category, at least on the node side of things.
Re: ES modules are terrible
#169question: // ... if (condition) { const x = require('../../../hugeFuckingLibraryThatTakesSeveralSecondsToLoadUponColdStart') // do something with x } // ... assume I don't give a fuck about nerd bullshit and I just want the code to be simple and the program to run fast (which it does when !condition because it doesn't need to load hugeFuckingLibrary), can I replicate this behavior with ESM?
You can replace that require with `await import(‘giantLibrary’)` but now your function needs to be async, and so do all of its callers. This is needed because it’s unacceptable to block the UI thread synchronously importing code in the browser, but in CLI programs not being able to synchronously require is a bit annoying.
that's a shame, I hoped there was going to be a way to do that and it was simply not implemented in node at the time I was looking into it
Re: ES modules are terrible
#170Earlier quoted context omitted.
Could you please point to “strange things” that people do with “exports” AND how it prevents static analyzers from doing their job? Why they can do it for: var x = strange_thing() but suddenly can not when “x” is renamed to “exports”?
Eg. module.exports = {foo: 3}; setImmediate(() => module.exports[Math.random() > 0.5 ? 'foo' : 'bar'] = 5); This is impossible for ES modules, because exports are static and known at parse time. Few widely used packages do something like: enhanceWithAdditionalProperties(module.exports, mixin);
Not the same but similar:
export var foo = 3
setImmediate(() => {foo = Math.random()})
export default var exports = { }
enhance(exports, mixin)
I see these subtle differences, but fail to see how they are a solution to the problem of “doing strange things to exports”.