Don’t agree with this take. Sacrificing the performance for all my users so a minuscule percentage of them can poke around a little easier? All the JavaScript is likely transpiled anyway. They can use dev tools to unminify most of it. Deploying with source maps for production might be a better ask?
Minification Is Evil
21–30 of 93 posts
Re: Minification Is Evil
#22I don't understand; I'm not going to increase the size of my assets just to please the very small minority of hackers who want to play around. I'd rather open-source my code.
which is actually a security risk
Re: Minification Is Evil
#23Don’t agree with this take. Sacrificing the performance for all my users so a minuscule percentage of them can poke around a little easier? All the JavaScript is likely transpiled anyway. They can use dev tools to unminify most of it. Deploying with source maps for production might be a better ask?
Or just making the source available on github.
Re: Minification Is Evil
#24No.
Re: Minification Is Evil
#25Not minifying your code is evil from the viewpoint of people who have to wait for your page to load.
An easy solution would be integrating a code unminifier/beautifier and viewer into browsers.
Re: Minification Is Evil
#26Soooo long gone are the days of the really compact website
There used to be a contest for best website that would fit into 5k bytes. [0]
Now, the bloat is so bad that there is a serious suggestion to nevermind the website, just make people download the entire cargo load and use it locally, merely to get acceptable performance.
If this does not tell us that the entire framework thing has gone too far, abstracted everything from actual speedy code, larded everything up with so much 'just in case' baggage code, etc... IDK what will.
Re: Minification Is Evil
#27I think minification should be done on another layer: HTTP compression and HTTP parallelization and that kind of stuff. And just don't make a complex web app, so it will be fast.
Re: Minification Is Evil
#28Not minifying your code is evil from the viewpoint of people who have to wait for your page to load.
Doesn't really matter after compression unless the bulk of your code can be culled from the end product. Tbh the largest business value this has is slowing down people trying to use your internal APIs.
Can client/browser choose if to use compression? If so, this is a problem for the website
Re: Minification Is Evil
#29Earlier quoted context omitted.
Doesn't really matter after compression unless the bulk of your code can be culled from the end product. Tbh the largest business value this has is slowing down people trying to use your internal APIs.
It would be nice to have experimentally-derived numbers to point to in order to help people visualize whether or not minification actually improves compression to any significant degree.
Here's an old article: https://css-tricks.com/the-difference-between-minification-a...
In the example given:
Original - 147 KB
Minified - 123 KB (83%)
Gzipped - 22 KB (15%)
Both - 20KB (14%)
Compression is waaay more effective, so if you have to pick one, go with compressing. Is having readable source code worth the other 2KB? That's up to you. Source maps can do the same thing with less, though. Also, modern devtools have ways of de-minification (if you don't mind all the mangled variable names).
Re: Minification Is Evil
#30With GZIP and moreso Brotli the difference in actual data transfer is negligible anyway. Minification doesn't really achieve much other than obfuscation these days.
Not everyone is on 5G. In rural zones and poor countries every kB counts.