Hacker News Reader

Comment by codemonkey-zeta | Hacker News Reader

So Deno is relying on native ESM imports in production code? Isn't that exactly what Vite _doesn't_ do, because of poor performance?

When you run the vite dev server it uses ESM, but when you build it uses rollup, because serving ESM is slow and with larger apps the client browser is going to make a bazillion requests. Wouldn't you rather traverse the dependency graph one time and bundle your code into modules so that everyone who visits your site doesn't force their browser to do it over and over again? Sure those dependencies will be cached between views or refreshes, but the first load will be slow as shit, then you still need to "code-split", just now you're calling it "islands".

View on HN

That sounds like an assumption that's not actually been tested recently. Downloading a 2MB bundle or 100 separate files is an equally poor experience, but the separate files at least let you download only the parts that changed over time, instead of having to download a completely new 2MB bundle every time someone changes a single letter in one of 100+ files and a new bundle with a new integrity digest gets rolled out.

I'd rather have an equally slow experience on first load, and then much better performance forever, compared to having something that constantly invalidates the entire cache.

I'm not sure what recent means, but I'm fairly sure (sorry, no references - only from memory) that it's been tested quite a lot, and also relatively recently (1-2 years?) by Evan (the guy behind Vite).

Even with newer versions of http just transferring lots of small files is noticeably slower (few percent if I remember correctly).

A few percent of a second is a few milliseconds, so no worries there, that's at the very edge of "audio visual desync" perception. For huge bundles, of course, a few percent of a few seconds can hit 100ms or more, but even that's barely noticable compared to how long we're already waiting for the bundle to download.

The bulk of the argument in favour of ESM in a "bundle vs ESM" comparison is in the cost of downloading updates: redownloading a individual ESM files (even several of them) is going to be appreciably faster than redownloading an entire bundle (even if the dependencies are split out into their own chunks and don't change).

A few milliseconds if you live in a first world country, sorry.

HTTP/2, which is getting pretty widespread now, mitigates most of the concerns about making a bazillion requests.

Here is what Vite has to say about it. [0]

Take a look at a few optimization it's able to do that the Deno guys will never even be able to dream of (otherwise they will reinvent Node.JS lol) [1]. The worst part is that the guy who created Deno is the same person that made Node.JS, if you don't like NodeJS I'm not sure why someone would be betting all in another of his projects, specially considering second-system syndrome is real and painful [2]. Deno is already suffering from feature creep, just recently starting to support package.json, which I find hilarious. Soon they will reinvent CPAN [3] and believe they just hit into something extremely innovative.

Does reading about CPAN remind you of something? Something that could be the same for JavaScript? Like a package manager for NodeJS?

[0]: https://vitejs.dev/guide/why.html#why-bundle-for-production

[1]: https://vitejs.dev/guide/features.html#build-optimizations

[2]: https://en.wikipedia.org/wiki/Second-system_effect

[3]: https://www.cpan.org/

h2 makes individual requests cheaper. However, if you have a waterfall of dependent resources where some must be fetched after others, you’re still waiting out the roundtrip for each edge in the longest chain. Which developers working and living 10ms from the data center usually don’t give a shit about.

Deno is an alternative to node and npm. You can have a Deno http server serving content to a browser. But the browser won't care how the server runs, as long as it can speak HTTP.

You can also use Deno to run your bundling tools, but again, what happens in Deno stays in Deno and does not reach the browser.

I think this is actually because esbuild doesn’t support everything needed in their production bundle (well controlled/grouped bundles) while it’s excellent for dev where there’s no such need.

I can’t remember where I read it, I think it’s in the official docs.

That's indeed correct [0]. esbuild is still a bundle though, so it wouldn't change much other than (much) faster production builds.

[0]: https://vitejs.dev/guide/why.html#why-not-bundle-with-esbuil...

Fresh is using esbuild to build the bundles at runtime instead of pre-deployment. So it rebuilds the bundles everytime a new process starts up and keeps copies of those files in memory for each process.

Reply on news.ycombinator.com