Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Minification Is Evil

todepond.com

Post reply on HN
Print view View original

51–60 of 93 posts

Re: Minification Is Evil

#51

Post by gustavus »

sanitycheck wrote: post #45

Sadly, not minifying source code can often lead to your idiot customer discovering that their web app is not a magic binary blob and complaining that it's "insecure! anyone can see how it works!", which then in turn leads to your idiot PM agreeing to a new "obfuscate all code" feature without bothering to involve anyone technical. Deliberately obfuscated JS is far more evil, take it from someone who's had to debug 3r…

At that point idiot PMs just need a technical discussion in the closet for an hour having the concept explained to them with a sock full of oranges.

Re: Minification Is Evil

#52

Post by umvi »

PaulHoule wrote: post #5

Not minifying your code is evil from the viewpoint of people who have to wait for your page to load.

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.

Re: Minification Is Evil

#53

Post by qwery »

This is cute. It's refreshing to see such a simple idea published on the internet in such a way. I also got a kick out of the URL.

Thanks for submitting it!

Re: Minification Is Evil

#54

Post by swells34 »

humbugtheman wrote: post #41
PaulHoule wrote: post #5

Not minifying your code is evil from the viewpoint of people who have to wait for your page to load.

Hi! Website owner here. How quickly did this page load for you? I make up for performance in other ways.

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!

Re: Minification Is Evil

#55

Post by PaulHoule »

aflag wrote: post #13
dimitrios1 wrote: post #8

Earlier quoted context omitted.

Or people who cannot afford unlimited data plans. 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.

Re: Minification Is Evil

#56

Post by rpigab »

jmull3n wrote: post #21

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?

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.

Re: Minification Is Evil

#57

Post by umvi »

sebstefan wrote: post #50
m4rtink wrote: post #34

Earlier quoted context omitted.

Doesn't gzip compression & source maps take care of this withou the abomination that is minification ?

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

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.

Re: Minification Is Evil

#58

Post by Michvalwin »

Zealotux wrote: post #18

I don't understand; I'm not going to increase the size of my assets just to please the very small minority of hackers who want to play around. I'd rather open-source my code.

Exactly. My largest page before and after minifiying has a size of 78KB~ and 70KB respectively. With GZIP it goes to 13.2KB. Just under the 14KB mark.

Re: Minification Is Evil

#59

Post by [deleted] »

umvi wrote: post #57
sebstefan wrote: post #50

Earlier quoted context omitted.

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

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…

[deleted]

Re: Minification Is Evil

#60

Post by sanitycheck »

gustavus wrote: post #51
sanitycheck wrote: post #45

Sadly, not minifying source code can often lead to your idiot customer discovering that their web app is not a magic binary blob and complaining that it's "insecure! anyone can see how it works!", which then in turn leads to your idiot PM agreeing to a new "obfuscate all code" feature without bothering to involve anyone technical. Deliberately obfuscated JS is far more evil, take it from someone who's had to debug 3r…

At that point idiot PMs just need a technical discussion in the closet for an hour having the concept explained to them with a sock full of oranges.

Finally, a good reason to return-to-office.
Post reply on HN