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.
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.
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
I make up for performance in other ways.
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!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.
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.