Hacker News Reader

Comment by cj | Hacker News Reader

Of course developers prefer faster build times. But what do the end-users who you write code for prefer? (Especially in a typical CI/CD environment where developers often don't need to monitor and wait for builds to finish)

2% sounds small. And it is, if your traffic is small. It's not small when you have millions of users.

View on HN

It's tiny, and usually negligible in context with all the other data that needs to be transferred, even with millions of users. Millions of users might be the situation where I'd start thinking of integrating slower builds as an alternative, provided they can seamlessly live side-by-side with the fast build tools.

Why would end users don’t care if there are a million other people getting a bit larger download size..? Accounts payable might care, but they aren’t end users.

2% file size reduction is probably an over optimization for a new startup searching for their first users.

But for an established product with substantial traffic, swapping out a js minifier for one that achieves even single digit % compression improvement seems worthwhile to me - if the only downside is adding a few extra seconds to build time.

End users prefer that we ship the features and squash the bugs they care about, which can be done faster with shorter build cycles. Our webpack prod build, which we have to run as sometimes minifying breaks things, takes 6 minutes. It’s the longest build step we have.

Reply on news.ycombinator.com