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

61–70 of 93 posts

Re: Minification Is Evil

#61

Post by tgv »

humbugtheman wrote: post #39
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?

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

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

Re: Minification Is Evil

#62

Post by KPGv2 »

kevsim wrote: post #38
meiraleal wrote: post #22

Earlier quoted context omitted.

which is actually a security risk

If people seeing your frontend code is a security risk, I've got some bad news for you...

the implicit argument you're making here is that the only acceptable security risk mitigation strategy is one that works 100% of the time

Re: Minification Is Evil

#63

Post by sebstefan »

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…

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 on the production environment

They can use the sourcemaps, or find the files on github

Re: Minification Is Evil

#64

Post by humbugtheman »

tgv wrote: post #61
humbugtheman wrote: post #39

Earlier quoted context omitted.

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

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

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

Re: Minification Is Evil

#65

Post by spiffytech »

umvi wrote: post #31
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?

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.

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

Re: Minification Is Evil

#66

Post by marcosdumay »

incrudible wrote: post #35
donatj wrote: post #20

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.

First of all, you're probably bundling your code, stripping comments, have tree-shaking eliminate parts of it. That's already a form of obfuscation. Then, minification will affect performance of parsing, it can even affect whether a function gets inlined by the JIT compiler, because character length is a very cheap heuristic. Whether I care about that or not is my judgement call.

> character length is a very cheap heuristic

Unless your interpreter is trying to optimize text blocks, op-code length will be cheaper and way easier to develop.

Re: Minification Is Evil

#67

Post by tecleandor »

kibwen wrote: post #19
BanTheBastards wrote: post #14

Earlier quoted context omitted.

Doesn't really matter after compression unless the bulk of your code can be culled from the end product. Tbh the largest business value this has is slowing down people trying to use your internal APIs.

It would be nice to have experimentally-derived numbers to point to in order to help people visualize whether or not minification actually improves compression to any significant degree.

Quick test I've done with some popular frameworks. I wonder if minification affects to parsing speed.

    +--------------------------+---------+---------+---------+--------+
    |         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 |
    +--------------------------+---------+---------+---------+--------+
Edit: something important to note: some frameworks (e.g. React) have lots of comments on their un-minified versions, that are removed when minified. That affects their size greatly.

Re: Minification Is Evil

#69

Post by tgv »

humbugtheman wrote: post #64
tgv wrote: post #61

Earlier quoted context omitted.

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

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

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

Re: Minification Is Evil

#70

Post by incrudible »

marcosdumay wrote: post #66
incrudible wrote: post #35

Earlier quoted context omitted.

First of all, you're probably bundling your code, stripping comments, have tree-shaking eliminate parts of it. That's already a form of obfuscation. Then, minification will affect performance of parsing, it can even affect whether a function gets inlined by the JIT compiler, because character length is a very cheap heuristic. Whether I care about that or not is my judgement call.

> character length is a very cheap heuristic Unless your interpreter is trying to optimize text blocks, op-code length will be cheaper and way easier to develop.

The existence of interpreter opcodes implies you have already compiled the code for the interpreter, but with this heuristic you can send this function straight to JIT.
Post reply on HN