Hacker News Reader

Comment by mapgrep | Hacker News Reader

Javascript minification seems like a classic case of premature optimization. I'm not a front-end developer so maybe I'm missing something, but wouldn't simple, transparent gzip compression via your webserver — one line in a config file — get you something like ~90% of the benefits of minification, for free?

I'm sure there are some additional gains to be made from knowing the syntactical structure of the language you're minifying, since no generic compression scheme can know that. But that seems really marginal — and, as the article in question shows, opens up potential security vulns.

View on HN

It depends on why you're minifying, but there are good reasons to do so. I'd bet, as in guess/speculate without evidence, that the #1 reason people do it is for code obfuscation. Front end JavaScript delivers source code to your users and competitors alike, that can be scary when you're working hard on something you think people will like & copy.

Most here are talking about uglify which does very superficial minimization, but Google's closure compiler is in the mix too, and that provides static type checking, nested variable flattening, dead code removal, inlining optimizations, and more. These things are substantial, not marginal, especially the static type checking. It's closer to C++ compilation than it is to gzip.

Gzip can be used (and usually is) either way, and generally still has some benefit even on minified code. But no, gzip can't replace or provide the majority benefit of a minification pass, they're two mostly independent things done for mostly different reasons.

I don't know if you could hide it from competition - it can be unminified ex with: http://jsbeautifier.org/ I have tried this before and it worked.

Google Chrome also does this out of the box (and has for awhile).

it depends on how you minify.

if you use Closure Compiler in Advanced mode it will rename and rescope pretty much everything except native methods and strings (making lots of globals cause it assumes you're compiling all page's code at once), it will eliminate unused code even from third party libs like jquery and do all sorts of stuff that make the beautified code very expensive to understand, follow and reverse and even then you may end up with only half a library that does only one specific task and the rest of the code would be missing.

you have to do a bit of JSDoc annotations in some places to fix some breakages and restructure the code a tiny bit to get it to rename absolutely everything but the results are excellent.

So, run http://www.jsnice.org/ over it?

tried it out and got an error saying it doesnt support ES5 getters/setters unless i change the language_in option. is there a way to do this?

even so, there's nothing it can do to bring back eliminated code, meaningfully extract inlined functions and scope everything appropriately to help a reverser understand context. it would still take an immense amount of effort only to get back something very specific.

the only thing you can probably get out of it is some largely mathematical chunks that cannot be restructured much, eg: rgbToHsv.

You can also just click the {} icon in Chromes debugger.

All you will get is a lot of function a with arguments z d and f calling eq on z and passing it d, then returning the qln value of the result.

Slightly more readable, yes, but still like debugging assembler.

It actually provides meaningful names, here is more about it: https://news.ycombinator.com/item?id=7836092

> it will eliminate unused code even from third party libs like jquery and do all sorts of stuff that make the beautified code very expensive to understand

To have that sort of optimisation you'll have to run the Closure compiler with ADVANCED_OPTIMIZATIONS enabled. Last time I checked that mode of compilation didn't work with JQuery and not with most other libraries. To use it with your own code you'll have to follow certain rules.

I think most people just use uglify or the Closure compiler in SIMPLE_OPTIMIZATIONS, neither of which does the very advanced stuff of ADVANCED_OPTIMIZATIONS.

Tools like this become increasingly useless as your codebase gets larger. For example, unminify React and try mapping functions to unminified code.

There is a lot to minification, these tools just undo cosmetic minification.

http://www.jsnice.org/ can do that – giving everything meaningful names, checking types, etc.

It can't give "meaningful names" without real context, which it doesn't have. Slightly longer names that are easier to read? Sure.

Yes, it can: https://news.ycombinator.com/item?id=7836092

Here's part of google homepage js thrown at it (In reality tossed a whole file, but pastebin wont fit it all for free). It's still entirely unreadable.

http://pastebin.com/VvEGZ8a3

If it can infer most of it from OSS? Sure. But big web apps do a lot more.

There are a lot of people who are doing it because it's suggested by Pagespeed Insights if you have any unminified JS/CSS/HTML, as well.

Another reason is that minified code + gzipped code is expected for third-party JavaScript widgets (social media buttons, in-app chat, ads, etc) because of legitimate developer concerns around page-size bloat.

I think the main reason that it's a best practice for people to minify their JavaScript files is for a smaller download size for the client. With a smaller download size, the page is able to utilize JavaScript at an earlier point and be ready for the user to interact with the page. Minifying and gzipping JavaScript yields a greatly smaller file size than without either. Big win for performance.

Just checking: are you saying that minifying and gzipping is better than gzipping alone? Where better means smaller downloads for the client?

I read that to mean that gzip / deflate was nearly as effective, and so there was not much reason to minify if you were already compressing.

While it is true that in practice, the size benefit of both compressing and minifying is optimal, the LZ77 algorithm is nearly the same as a minification algorithm, so running both has only marginal benefit.

Most of those benefits result in code that is faster to execute, the resulting code is smaller than e.g uglifyjs, but the main benefit is that the runtime performance is much better.

Let me present another reason for minifying that this thread doesn't seem to present. In React's codebase, we spread around lots of helpful warnings (those warnings are one of React's less spoken niceties), which goes through a processing step where `if (thisIsDev) {expensiveCheckThenWarn()}` turns into `if (false) {expensiveCheckThenWarn()}` for prod, and then the minifier guarantees to strip it out completely. For example, all the `propTypes` runtime type checking is gone in prod. Those were expensive.

For React-Native for example, I've heard people going from 15fps animation to 60fps when going into prod (!). I always tell them to benchmark their animation on the prod build, because dev build is _not_ representative of the perf you get.

Granted, it doesn't necessarily need to be the minifier's job. But that's the way things are currently done in JS.

If the minifier provides that much more incentive for helpful error messages then I'm all for it. It has helped us avoid a huge amount of duplicate questions when people start with React too. As a matter of fact, I think most libraries should adopt this approach for this feature alone (Webpack makes this process less of a hassle, but we can do better). Otherwise you'd be caught between inserting expensive checks and not inserting them out of perf concern, which would be a true premature optimization.

How much of that 15 to 60 fps speed up can be obtained simply by setting the variable thisIsDev to false without eliding the code?

"Gzipping alone gives you about 70% savings and minification alone cuts script sizes with more than half. Both combined (minifying then gzipping) can make your scripts 85% leaner." http://www.bookofspeed.com/chapter4.html

so really, minification only gets you 15% more size reduction.

Technically ~21% more reduction (e.g. saving 15k on top of 70k), but I suppose specific files probably deviate more than that anyway.

yeah, possibly. This is old reasearch [1] with oldish minifiers (e.g. no UglifyJS) and only one script - jQuery from 5 years ago. However I don't expect large discrepancies if the reseasrch is duplicated with new modifiers and larger sample.

What would be more interesting is to see the results of the different minifications. E.g. how much you get from simply removing comments and whitespace? How much if you also rename variables? There might be diminishing returns (and increased security risks) if you go further than those two simple and "safe" improvements

[1] http://www.phpied.com/reducing-tpayload/

Minifying alone is "kind of" important, and the benefits are hard to measure precisely with the combination of gzip, http/2, and the plethora of other network optimizations. However, the more sophisticated JavaScript compilers, like Google's Closure Compiler (https://developers.google.com/closure/compiler/) also do a lot of other compiler optimizations, like inlining functions, eliminating dead code, etc.

When you are working on a large engineering team with lots of JavaScript volume written by a lot of different people, the dead code elimination alone is worth it; it means you can use one function from a library with millions of lines and your compiled JavaScript will only contain that individual function rather than many megabytes of unused code.

Look at jQuery as an example[0]. gzip only saves you 4-5% over minification alone, but combining both techniques you save a further 20%. If you're not doing both you're leaving a lot on the table.

It's the same story compressing other material. 7-zip has filters to preprocess x86 and IA64 machine code to make it more amenable to LZMA, and such filters can get you a further 10-15%.

[0] https://mathiasbynens.be/demo/jquery-size

There are bunch of things you miss:

1. Gzip is not free. You would have to perform it on every single request. That costs money. Minification is a one time thing.

2. Gzip does not strip documentation.

3. Gzip, as you mentioned, cannot do language specific compression. So if your code is written poorly and can be better written with a closure, Gzip won't do that for you. Proper minification will.

4. Gzipping minified code is cheaper than gzipping non minified code.

5. Minified code uses lesser breadth of variable names and literals. This makes for more efficient Gzip.

As others have mentioned - Gzipping gives around 50% compression, full minification around 70%, and both combined around 80-90%. So if you go whole nine yards, you can save 40% extra on bandwidth. That could equate to thousands of dollars in saving every month for even a moderately famous web app.

You can pre-gzip, or cache the gzipped version; some servers do; in fact storing the gzipped version and occasionally uncompressing it for clients that cant do compression is much more efficient than the reverse as uncompressing is much faster.

You can store both on disk, apache at least, will figure out if the client can handle gzipped content and will send the compressed version when possible.

Same for nginx, using the gzip_static module: http://nginx.org/en/docs/http/ngx_http_gzip_static_module.ht...

But doing cache in this way sort of defeats the argument. Why would one cache a gzip copy instead of minified or minified+gipped? And minified alone is more efficient than gzip and can work regardless of client preference.

The argument here is why not simply use gzip and not use minification at all.

> Gzip is not free. You would have to perform it on every single request. That costs money. Minification is a one time thing.

Do it once and cache.

GZip - purely for bandwidth savings

Minification - combination of bandwidth savings and smaller code

Remember that Javascript on the client must run once per page load / per script inclusion. The larger the code, the more that must be parsed and executed.

Minification probably had more of an impact before Chrome+V8 when JavaScript engines competed to become extremely optimized. I suppose now most vendors have some sort of in-memory cache for recent scripts feature which would vastly reduce the average script execution due to the need to parse less frequently.

All benefits of sending less data over the wire aside, my understanding was that a significant portion of time during page load is spent actually parsing the js, and that one of the primary benefits of minification is that it reduces this overhead for sufficiently large pages. I notice that nobody has mentioned this, am I wrong?

You're absolutely correct that gzip compression will, in almost all cases, get you nearly all of the speed benefits minification will, and is generally a better method (and easier to do, as well). The reason so much JS, CSS, and HTML gets minified, in my opinion, is entirely a function of Google Pagespeed Insights. Regardless of the actual speed of your site, and regardless of the presence of gzip compression, if you have unminified JS, Google will recommend minifying it. They'll give you an estimate of how much you'll save, but even if it's low, the tool is generally used by average web users (ie, not true developers) who simply take Google's advice on its face.

You can do both and get a smaller file. A smaller file is a good thing, because networks are slow to send data.

You can often get a further 10% saving on top of what you get from gzip, and many of us think a 10% saving is not to be scoffed at: not everyone has a high bandwidth connection, and many mobile users are still charged by the megabyte.

People minify js files because they can.

When you already have a pipeline like gulp or grub (and if you are developing JavaScript, you should), adding minification is just one more line of code. So, why not minify if it doesn't represent any effort and it could mean better performance? Also, usually, developers don't have access to the production webserver.

Most of the time, people are to busy to analyze all the pros and cons of every action they do.

Said that, if Debian is an open source OS, then yes, they should have access to the unminified code of the applications they include. Or, at least, the sourcemaps.

Anecdotally I've heard of cases where minifying a script (running through the "uglify2" tool) led to extreme and obvious performance issues (like the UI thread freezing for several beats in cases where unminified JS did not).

In that case, the problem doesn't happen because we are minifying the files, but because this particular implementation of the minifier has a bug. I guess...

In particular, it was only an issue when identifiers were mangled (i.e. made as short as possible).

Yes, it's a classic case of premature optimization.

* As you mentioned, you get most of the benefits from gzip compression. * You pay a major debugging penalty for having your code minified, since it's much harder to figure out what happened with minified code. * After the first request your code is going to be cached locally, anyway, so we're only talking about the initial request. * Using a CDN for your libraries will buy you much more. It's not 100% relevant, but if you're worried about download speed, this is one thing that does make sense.

The main differences are gzip doesn't strip out the documentation, and you don't need to decompress it. So in some cases the minified version would be smaller and a bit quicker. YMMV. I think it's trivial and you're right. Using gzip is easier and a bit more transparent.

Related article I found: http://engineeredweb.com/blog/why-minify-javascript/

10% can be a lot. We have plenty of data that conversions go down as page loads take longer, even by tiny amounts that you wouldn't expect to have an effect.

I'm a front-end developer and you are absolutely right.

I've worked on embedded systems with tight resource constraints.

Minification was used on those systems because the space savings resulted in performance improvements.

Deminification would be less of a security concern than potential issues being introduced by minification.

I remember having to do this with AS2 systems, short variable names were faster.

Part of the benefit of minifying is obfuscating the code, the only way to strip out all meaning is to have a minifier that understands the syntax.

Why would you want to obfuscate the source code of a package?..

Because it's delivered over the wire to every client that requests it..

This is not a problem for Debian.

It may seem really marginal, but any time you can save downloading assets on page load is money. Everyone should be using gzip already, but minification shaves off precious milliseconds on top of that.

Except that your typical web site using minification is leaving hundreds or thousands of milliseconds on the table in other ways. They are minifying out of habit, not because they actually measured anything going faster. If they actually measured, then they'd be looking at the number of assets per page.

Minified js doesn't need decompressing whereas gzip would, but I'll admit it's probably a minuscule amount of CPU even on a smartphone, especially if you cache the decompressed version.

IIRC, pre-SP2 IE6 didn't handle gzipped javascript properly, but those days are behind us.

Reply on news.ycombinator.com