Most people aren't making webpages that need a quarter million lines of JS. For a normal sized webpage, difference between raw gzipped and minified gzipped is negligable.
Or maybe even "modern front end" hello world apps now need a quarter of a million lines because "modern" JS devs use super mega react typescript which installs 1000 npm dependencies and requires a 30 second "build" to generate a huge monolithic minified tree-shook js blob. I wouldn't know, I just use vanilla JS for my web pages.
For a small file (github.com/runk/node-chardet, release version 0.7.0, index.js, 154lines, 4KiB)
Raw - 3.30 KiB
Minified - 2.05 KiB
Gz - 1.01 KiB
Minified+Gz - 0.81 KiB
That's a 25% reduction
Still huge. If minifying before gzipping multiples the size of my transfers by a factor between 0.75 and 0.40, I'm not skipping it for the one oddball that wants the sources in a human-readable format on the production environment
They can use the sourcemaps, or find the files on github
My point is that for most people, the size savings of minification are going to be miniscule because most people are dealing with small JS files. Not only that but it makes debugging a much bigger pain. You start needing to generate and distribute map files, you can no longer easily observe or modify state from Dev console, etc.
I'm not completely opposed to minification. Distributing some self contained library like OpenCV.js? Minify away. But minifying everything even application files under active development just impedes developer velocity IMO for very little benefit. You shave off a couple hundred bytes in exchange for worse development/debugging and ostensibly faster page loads but realistically the same page loads.
Or maybe even "modern front end" hello world apps now need a quarter of a million lines because "modern" JS devs use super mega react typescript which installs 1000 npm dependencies and requires a 30 second "build" to generate a huge monolithic minified tree-shook js blob. I wouldn't know, I just use vanilla JS for my web pages.