Hacker News new | past | comments | ask | show | jobs | submit login

Basically everything you wrote is wrong. Loading multiple files is never more efficient because compression works on a file at a time in that case, plus subdependencies start loading only after their parents finish downloading. This is CSS’ @import cascades all over again.

The wheels I’m talking about are the actual modules that exist on npm used in production by millions daily. Everyone here can write some code that does something common like, say, left-pad, and then they screw it in some obvious way that was fixed in 2014 by the third user of that library.

Sure I agree that having no build is nice, but user performance is not comparable and you’re limited to your own code.




You seem to be still holding a lot of assumptions from 2010.

In practice compression is not a big issue if you use something with a pre-defined dictionary specialized for HTML/CSS/JS, which is Brotli. The advantages of bundling are not exactly too large. Sure you might not be deduplicating some identifiers, but the lion's share of code in practice is normal javascript/CSS/html.

Also, in the long term, caching and the removal of code added by bundling more than makes up for any losses from compression.

Also, with Multiplexing there's no problem with download multiple files sequentially, because you don't need TCP handshakes and HTTPS negotiation, which were the reason for bundling in 2010. In fact, multiplexing multiple files might be faster in some cases, because you're able to parallelise the downloads and the parsing, rather than having to download a big bundle before parsing it.

There are of course caveats to this, but neither bundling or separate assets are silver bullets.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: