Low footprint by default, anyone who wants to inspect then downloads the extra, and for bonus points can even see the original typescripted version instead of the js.
Preempting because I know we tend to be a little out of touch here: yes there are still plenty of cell plans without unlimited data, mostly among the pay per month options.
Very few websites have optimised their assets and number of connections enough that the size of the code is the bottleneck. Moreover, code tends to be highly compressible. I doubt it really saves much bandwidth. All javascript build systems out there already does it, though. Not doing it would require people to go out of their way. I think that's ultimately the main reason people do it.
There are different aspects of minification though, right?
I don't know if you count tree shaking but I do know my main project at work has 60,000 files in node_modules and if all of those were incorporated in my bundle that would be a big problem. The "modern web stack" just wouldn't work without it.
I've done a lot of photo projects where asset optimization is pretty important because it is easy to get in a place where your site costs 4x as much to run as it should and just as easy to get in a place where you compressed files too much and your images suck.
I am getting into WebXR and facing even tougher problems of asset optimization since I do want to support 90 fps on the not-too-terribly-fast generic ARM Meta Quest 3. I'm sure there is more than one reason you can't upload images to Horizon Worlds but avoiding too many textures with too much detail has to be one of them.
Using the largest, unminified, single file I could find in my node_modules folder (which happened to be tsserver.js from typescript, 11mb and 185 000 lines long)
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
Source maps are a thing, which has the added benefit of letting you ship the comments if you actually care to educate your users on how your website works.
It seems you've stirred up the minification cargo cult, who all seem to be ignoring the actual performance data vs compression . Thank you for the article!
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.
Edit: something important to note: some frameworks (e.g. React) have lots of comments on their un-minified versions, that are removed when minified. That affects their size greatly.
> Edit: something important to note: some frameworks (e.g. React) have lots of comments on their un-minified versions, that are removed when minified. That affects their size greatly.
Nah, in a more serious note, to properly compare the impact of minification, I should remove the comments from the unminified (maxified?) version first. :)
Nah that wouldn't be fair, the code I serve my users initially has comments too and the arguments that people bring to criticize minification is that it adds complexity if you want to read the code in the browser. The comments should stay
Often I avoid comments by using long names for functions and variables (e.g. the test whose name is a statement of the postulate behind it) and minimization squashes many of those.
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).
IMO, if minification is the difference between a slow and fast page load, it means you aren't utilizing compression. Minification is more obfuscation than anything, it doesn't really bring much to the compression table.
Low footprint by default, anyone who wants to inspect then downloads the extra, and for bonus points can even see the original typescripted version instead of the js.