Comment by est31 | Hacker News Reader

Comment by est31 | Hacker News Reader

I'm not sure why this would be desirable. Sure, bundlers are slow, but that's what projects like pax [1] are for. Bundlers create one single file instead of the browser having to download your entire possibly huge dependency tree. Sure, with HTTP/2.0 and the upcoming QUIC or HTTP/3.0 overhead of this is minimized, but it's still not zero. There is also a cognitive overhead of having to configure the server to push all the deps to clients otherwise you have constant back & forth where the client is fetching a file, then the server is answering, then the client is finding out it needs those other files, etc etc. Unless you are using global CDNs, expect latencies to be > 50ms for each such step, if not hundreds of ms, and this times the depth of your dependency graph. Bundlers also do dead code analysis.

There are really two solutions to this: either avoid using js dependencies, at which point you won't need npm or pika or whatever, or use bundlers.

[1]: https://github.com/nathan/pax

You probably won't end up with a dependency tree. Remember development in 2007? Remember this?

    <script src="https://cdnjs.cloudflare.com/ajax/libs/jquery/3.3.1/jquery.min.js"></script>

Under ESM, each of your dependencies could go back to being a (CDN or /vendor-directory) hosted "release." The release would have been packed together into a single JS file + a single CSS file by its developer, when it was published. There would be no reason to further run a bundler just to turn ~5 such pairs of files into one pair. Over HTTP2/3 that difference is negligible.

It's non-negligible for "thousands of dependencies", of course, but nobody would be doing that. "Thousands of dependencies" is for library development, not for library release packaging.

NPM (or Pika) is still useful under such a paradigm, for the same reason Cargo or Bundler or Pip or Mix or whatever other tools are useful: these tools let you specify your direct dependencies using symbolic version constraints, and then retrieve+update+lock those dependencies. This is helpful whether your direct dependencies are "baked-down" release packages or raw deep-dep-tree source.

That's worse because you lose the ability to "tree-shake". It would go back to importing all of Underscore on a CDN versus bundling the few functions you need into the main bundle.

OTOH, if you use a "standard" library from a CDN, it's quite possible that the end user already has it cached.

That never really works out in practice when there's so many versions and then you're at the disposal of a public CDN, which can be the bottleneck, especially when it's critical code.

Sure you can fallback to local copies, but that just means your app hung there for X amount of time, and the added complexity of adding fallback logic.

Plus if you look at the size of these libraries, especially utility libraries (date-fns, underscore, etc) they are huge, and you usually only need a few functions. Relying on cache will never be a bigger benefit than tree-shaking.

Sure you could manually try to extract those functions, but that's a much much worse developer experience.

That never really works out in practice

So glad this was such dominant practice and advice for the last 10 years. I wonder for how many of those influential practictioners have known it's more of a lazy include than clever cache reuse. Cargo culting writ larger than most.

It really depends. I think CDNs are still great if you are making smaller content website with few libs for things like lightboxes, sliders etc. It works out better than bundling. There is much less complexity without build process. Many websites don't need too much JS and devs tend to overengineer them nowdays.

If you are talking about products with lot of dependencies then of course but don't forget that bundler situation used to be completely different. There is not that much of difference (besides number of requests) between concating libs in sequence and loading libs in sequence.

I'm speaking to the jquery example. 99% of howtos have instructed people to pull from CDN because everybody (probably) already has it. It has been conventional wisdom for a long, long time.

I just checked, and googling "jquery cdn faster" brings up plenty of examples.

One major benefit is that for any given page in your application, you probably don't need the entire bundle.

This is not really true for SPA's, but I hope that's a trend that will eventually sizzle out again except for specialized cases.

Just grabbing what you need can have significant benefits. I agree with the latency problem though, it would be nice to have a HTTP/2 or HTTP/3 server that has a basic understanding of the JS dependency tree and preemptively push the entire tree.

Here's the problem I'm struggling with:

1. Typically, you only ever care about minimizing bundle size in cases where latency is consistently questionable

2. In those cases, whatever UI you're supporting is likely then not meant for latency-sensitive operations, and thus the overall workflow tends to have low state complexity

3. Just how much actual value is added in those scenarios by having the ESM workflow specifically in conjunction with importable NPM modules?

I'm sure you can think up some contrived use cases but I'm just not seeing any particularly compelling ones.

No it's not just latency. In fact, that's not even the most important factor. On mobile devices if the script is too large, it will freeze while parsing.

> This is not really true for SPA's, but I hope that's a trend that will eventually sizzle out again except for specialized cases.

I suspect we'll see the opposite, with people building desktop type applications and deploying through the browser (especially with the growth of wasm)

nuxtjs and webpack4 are actually automatically bundling dependencies so that libraries are automatically included only on pages that use them.

How does pax compare to fastpack?

https://github.com/fastpack/fastpack

Reply on news.ycombinator.com