5 ms·
In pretty much every case minification is going to reduce the payload, which is going to reduce the amount of data a client has to download. Whether you're mini
by joekrill 9y ago
In pretty much every case minification is going to reduce the payload, which is going to reduce the amount of data a client has to download. Whether you're minifying 1KB down to 100 bytes, or 50 MB down to 3 MB -- you're still benefiting.
I can't really see a case where that is a bad thing, particularly when you have source maps to get you back to the original source code, anyway. Your stance just seems very naive.
- Spearchucker 9y agoSource maps have never worked out for me, and my pages are tiny (I see no benefit in sacrificing readability for a reduction from 1K to 100 bytes).
- rimliu 9y agoThat's an interesting claim about readability. You may as well argue that compilation of C program reduces its readability. Minification should be a step of making a production build. It does not affect source code and thus it does not affect readability.
- lmm 9y ago> You may as well argue that compilation of C program reduces its readability. Minification should be a step of making a production build. You can't run C without building it, so you have to do some kind of compilation. I've certainly known people to argue for e.g. including debug symbols even in the build you ship to customers - the savings from stripping them aren't worth the added complexity and difficulty of debugging.
- romaniv 9y agoSmaller files are never a bad thing in themselves, but increasingly complex toolchains have a maintenance cost that people don't seem to notice. And I'm not just talking about making them work. I'm talking about everything, including choosing, learning, upgrading, replacing, dealing with problems people talk about here and even reading this article. I'm not sure how we got to the point where something that worked without minification on year 2000 networks no longer works without per-processing on year 2017 networks.