Hacker News new | ask | show | jobs
by donatj 944 days ago
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.

3 comments

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.
I just checked: 514kB gzip vs 314kB minified+gzip. Not negligible, IMO.
How big was your original JS package that it gzipped down to 514kB? Like 30 megs?

Really sounds like you have bigger problems.

It's a large web app, sure, but gzip doesn't do 60x compression. 9-10x at best. But it's not a problem. It's for a small-ish group of people, and it's better to do the editing and some processing in the browser than on the server. The app uses relatively few components in that build at the same time, so it's not sluggish. There are also some "assets" in there. I don't like the practice, but my colleague does, so he occasionally puts things like images and fonts in there.

OTOH: it shows data. A normal size data set is 2000-3000x rows and 300-500 columns. If you output that as a simple table, the browsers gets super-slow. So another component has to be added. It adds up.

Not everyone is on 5G. In rural zones and poor countries every kB counts.