3 ms·
No, I vastly prefer 10x faster build times and merely 2% file sizes over anything that's on order of magnitude slower. It's not even a competition.
by mschuetz 6y ago
No, I vastly prefer 10x faster build times and merely 2% file sizes over anything that's on order of magnitude slower. It's not even a competition.
- cj 6y agoOf 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.
- mschuetz 6y agoIt'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.
- jakear 6y agoWhy 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.
- cj 6y ago2% 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.
- jahewson 6y agoEnd 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.