I agree with the recommendation of one good compression algorithm vs combining multiple in general, but is it possible that you hadn’t considered that this is a case where we have a very good lossless compression (gzip) that can get benefits when combined with a lossy compression (minification)? As wonderful as Huffman codings can be, it’s hard to compete with outright throwing “unnecessary” (to many users, maybe not OP and some of us) data away.
I'm sure some people here will agree with that sentiment, but for the majority of users it's the better option. And if the goal of the project is for the source to be open then they can host that source somewhere for those who want to tinker, inspect, or build their own binaries.
At some point most web apps will probably be blobs of WASM anyway.
Wondering how to reconcile this with the never-ending didactic missives from software developers about writing code that others can easily understand. Generally, the affection for verbose languages and disdain for terse ones.
There is also a trust problem. How can we be sure that minification is only for the purpose of performance and not also for the purpose of obfuscation. For example, from the user's perspective, performance is routinely sacrificed to allow for advertising. Users must wait and allow their computer's resources and network bandwidth to be usurped for telemetry, ad auctions and ads they really do not want to look at. This is almost always orchestrated using Javascript.
There so many more ways to improve performance without minifying code.
I make up for performance in other ways! Let me know if any part of my website(s) run slow
Minification’s more useful for web applications, along the lines of: MS Office (e.g. Excel), Zappier, UberEats, Photoshop, the reporting side of analytics (e.g. Google Analytics) where you get all the interactive graphs and maps.
I think many of the disagreements on here would dissolve if they were only considering blogs and similarly small websites.
As a tangent: this is a neat tool! :)
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.
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.
Raw: 11 403KiB
Raw gzipped: 1 881 KiB
Minified: 3 543 KiB
Minified gzipped: 865 Kib
A 2.17x reduction between the two gzips
Even with GZip, minification is huge
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.
I make up for performance in other ways.
+--------------------------+---------+---------+---------+--------+
| Library | Size | gzip -1 | gzip -9 | brotli |
+--------------------------+---------+---------+---------+--------+
| bootstrap.css | 280813 | 47312 | 33109 | 24533 |
| bootstrap.min.css | 232948 | 42003 | 30776 | 22695 |
| react.development.js | 87574 | 28733 | 23513 | 19818 |
| react.development.min.js | 25612 | 10217 | 9224 | 8052 |
| tailwind-2.2.19.css | 3642321 | 376787 | 304100 | 82049 |
| tailwind-2.2.19.min.css | 2934019 | 354063 | 294632 | 72803 |
| vue.global.js | 476920 | 134655 | 105130 | 87121 |
| vue.global.min.js | 167898 | 74769 | 65582 | 57922 |
+--------------------------+---------+---------+---------+--------+
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).
At least with jQuery, it seems that minification matters considerably.
Do not minify
Your front end is insightful
Let people inspect There once was a proud web designer
Whose code ‘pared with most was far finer
Yet he minified
And nobody spied
The great masterpiece of Brent Spiner!every system has an attack surface. If you make yours easier for any person to use "alternative" paths, I also got some bad news for you.
Minification doesn't really achieve much other than obfuscation these days.
Unless your interpreter is trying to optimize text blocks, op-code length will be cheaper and way easier to develop.
Really sounds like you have bigger problems.
OTOH: it shows data. A normal size data set is 2000-3000x rows and 300-500 columns. If you output that as a simple table, the browsers gets super-slow. So another component has to be added. It adds up.
Deliberately obfuscated JS is far more evil, take it from someone who's had to debug 3rd-party obfuscated JS libs.
Because as noted below minification is much less impactful than compression, but going even further, if you really care about performance the solution is as simple as not shoving 20 metric boatloads of JavaScript in your website in the first place.
If you're argument I'd "muh rural customers" then maybe you should actually look at how your website is designed and ask yourself if you need to ship 3 different frameworks to accomplish what you need to do, or maybe start by stripping out the bloated analytics and ad nonsense in your code.
At the end of the day the author is right, the arguments about whether minification is useful is a teachincal argument, but the business will always want it for the purposes of obfuscating their code, and so we need to push back against the idea of it being an industry norm otherwise managers will push to make it so.
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.
In some of my more logically involved code, the bulk of the bytes are in comments - and they barely compress at all.
Just minify. Nobody cares about your source code; if they do and you want them to, publishing on GitHub is far better as it allows for viewing the TS/ESNext version and separate files too (don't tell me you aren't bundling!!); and working with minified code is not hard, especially now that dev tools have built-in maxifiers.
I publish to github too! It's nice to let people download my stuff and tinker though, straight from the website itself :) They can also tinker there and then in the browser.
I'm not trying to convince you either way – it's clear we have a different set of values.
Thanks for submitting it!
Think ASM disassemblers - arguably a harder task and people do fine with it
I never thought about that, I will just tell my customers that I removed all non-trivial features to make the app load faster. Also, there won't be any new features. I'll report back on how it goes.
Lots of apps include features that were never really asked for by the customer, but are included because it was easier for the developer.
But I agree, there is not really much point to minification for small or medium websites. Transport compression takes care of file sizes.
I was on a brief kick of interest in
https://en.wikipedia.org/wiki/E-Prime
which of course eliminates structures like "X is Y" but I realized I could still write stuff like "With utmost evil, evil webmasters minify their evil web sites for evil reasons that make sense only in the evil world view of evil people"
Nobody cares about the source, let website authors do what they want.