81–90 of 93 posts
Earlier quoted context omitted.
Did it run slow for you? How many milliseconds? :)
You're just begging for the remark: then output an empty file. Super speedy.
Check out https://tadiweb.com for more
I 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.
> just don't make a complex web app, so it will be fast 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.
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.
Lots of folks outing themselves as never adding comments with remarks like "compression works nearly as well as minification". 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 separat…
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.
Earlier quoted context omitted.
Do you have any strong example websites? The website you linked is very simple, I can’t see why most pages on it would benefit from using JS at all except for analytics or similar. It’s a good website, I don’t mean to make it sound otherwise, but it’s not the type that should consider minifying code in the first place. Minification’s more useful for web applications, along the lines of: MS Office (e.g. Excel), Zappie…
Self-reply: I see that the website links to tldraw under Job, which might be a good example to weigh the shipped size vs the same thing minified, except that it's already minified. As a tangent: this is a neat tool! :)
The fact that stuff has to be minified is evil.
Sometimes it's a good idea to minify.
It's still evil
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?
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.
Earlier quoted context omitted.
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 mini…
Okay. Let's move goalposts. 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…
With GZIP and moreso Brotli the difference in actual data transfer is negligible anyway. Minification doesn't really achieve much other than obfuscation these days.
I just checked: 514kB gzip vs 314kB minified+gzip. Not negligible, IMO.
Really sounds like you have bigger problems.
Earlier quoted context omitted.
Okay. Let's move goalposts. 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…
Saving 200 bytes is "still huge"? For me 200 bytes is not worth the extra headaches minification introduces.
This is about the general discussion around minification. I don't care the specifics of your particular usecase.
The point is that it reduces filesizes even after gzip. You having an arbitrary threshold around 200 bytes is not interesting.