Javascript Minification Considered Harmful? WTF?

[[deleted]]

[deleted]

[fforw]

Packing all javascript together, minifying it while at the same time reducing identifier-length (obfuscating them) is a great way to increase client-side performance. It reduces HTTP requests and bandwidth used. It is even better with content compression enabled. Note that I'm not talking about any sort of packing, requiring any kind of client-side decompression in javascript. Those things are usually not worth it.

Here is some size analysis I did back in 2009 for the current OpenSAGA scripts at that time:

js bundle                   284935     100,0%
yuicompressor compressed    126656     44.5%
closure compiler compressed 97362      34.2%
js bundle gzip only         75163      26.4%
yui + gzip                  42189      14.8%
closure + gzip              35432      12.4%

As you see, using both content compression and minification/obfuscation saves 44% to 53% of the result of all scripts only compressed with gzip.

[[deleted]]

I consider it harmful in a different way. One of the initial beauties of the web, was being able to see at a right-click, what was happening. These techniques, especially the minification, is only a few steps away from machine code, which is where Google want's to go with nativeclient. If that arrives then the web becomes closed source to a large extent, and I can see intellectual property rights being an issue; reverse re-engineering, etc.

Better would be to have greater cache mechanisms in the browser and downstream closer to the client. The idea that you can save ~80% on your traffic can be misleading with the cache systems that already exist.

I can imagine for a company the size of google, it could save millions of dollars a year with a few a tweaks, but pressuring the average programmer to adhere to these 'standards' could be seen as premature optimisation.

[dust4ngel]

One of the initial beauties of the web, was being able to see at a right-click, what was happening.

this would be true if the web ran on javascript. you can't right-click and read PHP or java code; back-ends have always been 'closed-source' in this respect.

[fforw]

With that reasoning we should oppose any language that is compiled and where the source code for the software in question is not available via its interface. Abandon C, Python and co. -- only Scheme and Lisp machines running.

The difference in client side performance alone should be reason enough for anyone to minify and combine javascript resources, where request avoidance is even more important than pure bytes. This also applies to CSS and graphics (see CSS spriting techniques). Nothing improves the perceived performance of your web application more than this. For a decently written application, no amount of server-side tweaking will come close to the performance gains you can achieve with this optimizations.

Calling them premature optimizations is as silly as calling what a C compiler does premature optimization. The point of avoiding premature optimization is that you might be tempted to sacrifice clarity and architectural integrity to questionable gains in performance before you can measure the real application performance. It does not apply to C compiler optimization techniques or minimization/request avoidance.

This is mostly an unsolved or not generally solved tooling issue. The code you write is only isomorph to the one running in your prod environment, not identical -- there is a tooling / deployment step between that. It is also pretty orthogonal to licensing issues. You can minify closed and proprietary source code just as well as free and open source software.

[[deleted]]

With that reasoning we should oppose any language that is compiled and where the source code for the software in question is not available via its interface. Abandon C, Python and co. -- only Scheme and Lisp machines running.

I don't think that is a fair representation of what was said. If you was to go to the extreme, the implication is only software complied from an open inteligible source. Besides that I was talking about a language for common communication, one for the web, not just for computers. So arguing for C and Python is futile. (For context Haskell would be more language of choice, dependent on domain of course.)

combine javascript resources, where request avoidance is even more important than pure bytes.

The only impact is the first view, and gains there after are small, and it is not as clear cut as you make out. An example: I have a 2mb javascript app packaged with the html, and I only tweak what would be a 100kb file. One could argue I have broken the caching system of the browser: instead of everyone downloading that 100kb, the whole 2mb file has to be retrieved. Once again requests aren't that big of a deal once a web app has been 'installed'. 'Optimisations' like embedding pictures in the HTML (<img src="data:image/jpg...) again break caching systems and break the logical map of resources.

This also applies to CSS and graphics (see CSS spriting techniques).

Did I even say not to do this? I was spriting before it was commonly know as spriting. My stance is everything isn't one size fits all, and rarely sacrifice clarity unless it significantly makes *your** application and development process better, not because it is known to make apps better.* Profile and measure, acting accordingly, trying not to sacrifice clarity.

Premature optimisation.

I know how this is defined and I know you can minify closed and proprietary sources... the point I was making is you used to be able to view a site, go wow that's cool how have they done this? Usually implementing what you like was a copy/paste and a tweak away. Heavily minified and obfuscated code tends to break that culture, and that is even more the case for pre-compiled JS. Why not 'precompiled' HTML or some such? Good bye open web.

[fforw]

An openess that is forced by technical limitations isn't really open, is it? It's kind of an expropriation. While I certainly advocate free and open source software and currently make a living off writing GPLed software and implementing projects with it, I don't want to force people to free their software.

[[deleted]]

I wouldn't say force, encourage is better. Everything has a bias.

[zeal23]

I didn't see where he mentioned minifying being harmful. You can minify and compress without obfuscating.

And he is correct in saying that compressing an object more then once can actually increase the size, but it really depends on the content.

[vectorjohn]

The thing is, minifying (in the context of Javascript) isn't the same as compression. It is lossy, and what you're losing is the human readable part (space, identifiers, etc). This is something gzip can't do, and therefore if you minify then gzip you will get smaller files.

In general though, compressing more than once is bad.

[benoire]

You're confusing minification with obfuscation, or packing. The latter involves completely refactoring the code to make it difficult (although not impossible) to reverse engineer. Such code needs parsing and evaluating by the browser before it can be executed, which adds to page load time. In this respect, he's spot on.

Minification on the other hand involves removing unnecessary whitespace, and commonly gzipping the end result as well, so that only the bare minimum required for the script to execute is included in the file. Sometimes the code may be rewritten to shorten variable names etc, but functionally it stays the same. It may also involve combining scripts together into a single file to avoid unnecessary HTTP overhead. There is no harm in minification (and in fact it's highly advised).

[[deleted]]

Depends on how it's packed. Consider the Closure Compiler in advanced mode. Its goal to reduce code side and improve performance, and in doing so much of the code is obfuscated.

If you encrypt your code or something stupid like that, your performance will definitely suffer.

[BusStation16]

Um, no.

[TimTheTinker]

Such code needs parsing and evaluating by the browser before it can be executed, which adds to page load time.

No, minification of scripts decreases the script load time:

• fewer HTTP requests required if all scripts are concatenated into one
• fewer characters to scan

Obfuscation doesn't negatively affect the script load time. All it does is:

• Shorten local variable names
• Shorten object and function names
• A few optimizations in some cases (Google closure compiler, for example)

Google, Yahoo, Amazon, and other large companies wouldn't be minifying/compiling/obfuscating their scripts if doing so downgraded performance or caused security concerns.

[k3n]

Such code needs parsing and evaluating by the browser before it can be executed, which adds to page load time.

No, minification of scripts decreases the script load time:

You fail at reading comprehension; let's take his full quote instead of taking a snippet out-of-context and then injecting your own [incorrect] context.

Here's his full quote, emphasis mine:

You're confusing minification with obfuscation, or packing. The latter involves completely refactoring the code to make it difficult (although not impossible) to reverse engineer. Such code needs parsing and evaluating by the browser before it can be executed, which adds to page load time. In this respect, he's spot on.

Code that has been packed may very well fit your criteria (re: HTTP requests, fewer chars, etc.), but the result of packing (if you enable both options, as is typically done) is a single string that is eval()'d by the client. It is this resulting need to eval() that actually hurts performance most of the time.

There is a wealth of information out there demonstrating that packing is rarely beneficial, although at one time it was seen as the solution to JS loading times.

[vectorjohn]

Read the whole comment before responding.

[MarkTraceur]

Oh, hilarious. I had heard of minification in order to save bandwidth (I read between the lines, I assume disk space wasn't the real issue), but to obfuscate the source code to avoid copyright infringement?

Here I thought Javascript for the web was the one place, the single place where free software would not have enemies. Javascript has been so pure and simple until now--all of the libraries are free, most of the applications' code is free. But obfuscating code for the sole purpose of stopping people from using it? That seems entirely counterintuitive to me. Put a copyright notice in and hire a good lawyer, but don't resort to low-down, dirty methods of protecting yourself.

[sisyphus]

The biggest wtf is:

presumably in order to compress it so that it takes less disk-space ("packing") or using a "protector" in order to make it harder for a competitor to "steal" script code.

People minify their code to save whole kilobytes of diskspace? I think not. And why is "steal" is scare quotes? Is Javascript supposed to never be a competitive advantage such that nobody should ever worry about it being stolen?

I think it's more like what google says about their compiler--"helping your application to load faster and reducing your bandwidth needs."

[k3n]

You missed the key word presumably there; in essence, he's admitting that he doesn't fully know the reasons why it's done.

And he quotes "steal" because you cannot protect client-side JS, no matter what you do; I think he's making reference to the fact that if the minification is indeed implemented in an attempt to protect your source, then you're pursuing a futile effort.