[jmull3n]

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?

[umvi]

How big is your JS that minification has measurable performance impact? In my experience, minification doesn't add much (if anything) on top of gzip + cache for most applications.

[marginalia_nu]

Yeah, the way compression works, I wouldn't expect minification to reduce the transfer sizes to any significant degree, as it's basically layering a good compression algorithm on top of a bad one. In general compression algorithm matroshka dolls tend to be inferior in terms of size and speed when compared to just using one good algorithm.

[robinson7d]

All of the comments on this post that include numbers show that using both is better than just one or the other, mostly when the code’s sufficiently large.

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.

[marginalia_nu]

Does still sort of does come off as majoring in the minors.

As illustrated by the examples in this thread, the actual benefit of this isn't particularly large, and it comes at the expense of worse developer experience. At the point where this would actually have a real measurable performance impact, your application is so hideously bloated there is without a shred of doubt other things you can do to improve the performance of your application that is more impactful than minification.

[spiffytech]

Transfer time is only a part of the story. JS parse time has a measurable impact on page speed, and scales with character count.

[vxxzy]

Given enough request it could add up. Maybe not big savings for a majority of sites though.

[stetrain]

Yep. This is basically like saying "don't distributed compiled binaries"

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.

[1vuio0pswjnm7]

"Sacrificing the performance so a miniscule percentage of them can poke around a little easier?"

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.

[shortrounddev2]

Or just making the source available on github.

[rpigab]

My HR web service, used to check if colleagues are on paid leave, has a paginated view of an html table of paid leaves, 30 people per page. A single page contains about 2 million times the character "space", which in the vast majority of html rendering, is completely ignored (exceptions when they actually separate symbols and when they're present in raw text rendered as-is).

There so many more ways to improve performance without minifying code.

[humbugtheman]

Hi. Article writer here. Sourcemaps are pants and a nightmare to deal with.

I make up for performance in other ways! Let me know if any part of my website(s) run slow

[tgv]

Your landing page doesn't even add html tags. Firefox says it's in quirks mode. That's not making up for performance.

[humbugtheman]

Did it run slow for you? How many milliseconds? :)

[tgv]

You're just begging for the remark: then output an empty file. Super speedy.

[humbugtheman]

Hey I do actually experiment with this sliding scale :)

Check out https://tadiweb.com for more

[robinson7d]

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), 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.

[robinson7d]

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! :)

[humbugtheman]

Thanks! tldraw is of course minified/etc because it's part of a bigger ecosystem (eg: React, and more).

The fact that stuff has to be minified is evil.

Sometimes it's a good idea to minify.

It's still evil