Hacker News Reader

Comment by bastawhiz | Hacker News Reader

Author of crass here.

I wouldn't recommend doing what the author suggests. crass doesn't squeak out extra bytes when you reprocess because it already does this for you.

If you combine multiple minifiers, the bugs in one minifier can end up being amplified by the others. For instance, one minifier might not consider !important when moving around CSS. Another minifier might then take that output and perform an optimization that's no longer just unsafe, but now incorrect. It might even delete rulesets that it believes are not used, ruining your stylesheet.

There are suites that test the correctness of minifieres, and many don't do great. CSS still "works" when the syntax is invalid, so invalid stylesheets result in undefined results when you minify. Between bugs and undefined behavior, I wouldn't recommend mixing and matching just to save one or two TCP packets, especially with gzip/brotli on the wire.

View on HN

I'm not recommending doing it either! :)

I don't recommend using minifiers which contain bugs or do unsafe transformations (a form of bug IMO).

Pretty much any transformation is unsafe under the right circumstances. That's why minifiers take a lot of config.

So you don't recommend using a minifier? In all seriousness, I don't think anyone is recommending using one with known bugs but there will likely always be some latent bugs that aren't known.

> I don't recommend using minifiers which contain bugs

I recommend not using minifiers. Or compilers, for that matter. Or really any software. ;)

> or do unsafe transformations (a form of bug IMO)

I think it depends. In crass, unsafe transformations are only performed when you pass a special flag to the API or CLI. The constraints and effects are documented with the premise "If you're not doing X, Y, and Z, we'll squeeze out a few more bytes". X, Y, and Z are things like relying on browser bugs or only using deprecated features (e.g., using -webkit-border-radius without border-radius). Folks using CSS preprocessors (SCSS, stylus, LESS, etc.) oftentimes don't have CSS that could cause issues, and this option is safe enough for them (and provides a hefty benefit).

The problem with CSS is that you can guarantee many things as safe, but because of the flexibility of the language, it's impossible to minify "perfectly". Having knobs and levers for the developer to say "I'm not supporting IE9 or below, yes you're looking at ALL of my CSS, no I don't care about browsers older than three years..." gives much better results--especially on large projects--by trimming down the number of variables that could prevent different sorts of "optimizations".

Even with one pass of a minifier it's possible to get bugs, so I wouldn't recommend reprocessing either.

Reprocessing one minifier's output with itself is probably fine, since you're not mixing and matching approaches to minification. It's likely that a minifier is consistent with how it minifies internally, and they simply don't do multiple passes.

Your time would be far better spent, though, making a pull request to properly implement multiple passes on your minifier of choice so that you can safely get that benefit. Or you could say "meh, I'm not losing sleep over the extra hundred bytes" and work on something more productive.

Reply on news.ycombinator.com