Javascript [LWN.net]

Javascript

Posted Mar 14, 2013 15:24 UTC (Thu) by rfunk (subscriber, #4054)
Parent article: SCALE: The life and times of the AGPL

It's worth noting that the Javascript obfuscation described here is most often done for the primary purpose of reducing the time it takes for the browser to download the code. For example, the version of jQuery I have here goes from 248k to 96k when "minified", reducing its part of the page load time by more than 60%.

On the other hand, there's also Javascript that's actually treated as object code, compiled from some other language into something that will run on the browser. The extreme case of this is code transformed by Emscripten into Javascript from anything that LLVM can compile (e.g. C or C++).

(Log in to post comments)

Javascript

Posted Mar 14, 2013 15:40 UTC (Thu) by serzan (subscriber, #8155) [Link]

Indeed, minified js is meant to reduce download time *and* is trivially reversible (eg. with UglifyJS).

Javascript

Posted Mar 14, 2013 16:59 UTC (Thu) by pboddie (guest, #50784) [Link]

The hilarious thing about the obsession with reducing resource sizes is that it often goes hand in hand with weighing down the average Web site with 20 different "parasite" resources, each providing things like "analytics", tracking, adverts, and even the actual JavaScript libraries that the site needs to "deliver its experience", so that the browser ends up hanging for ten seconds while today's bottleneck struggles to serve up JavaScript and other stuff that the offending site's developers were too cheap to host themselves (or too lazy to learn how to host themselves).

The Web has ended up as quite some distributed computing platform, where everyone ends up running programs for other people. It's just a shame that most of them are completely superfluous.

Javascript

Posted Mar 14, 2013 17:19 UTC (Thu) by rfunk (subscriber, #4054) [Link]

Without getting into what's superfluous or not, I'd like to point out that, quite often, sites will load resources from outside servers in order to *speed up* the load. That can work for a combination of reasons:

1. If you've already been to a site that loads the resource from the same place, it's already in your cache and your browser doesn't bother loading it again.
2. Browsers have a small limit of how many resources they'll load from a single place at once, so loading some of them from an outside server increases the parallelism of the load.
3. The outside server may use a distributed content delivery network, so that you'll get the resource from a closer server than you otherwise would,

Javascript

Posted Mar 15, 2013 13:11 UTC (Fri) by ibukanov (subscriber, #3942) [Link]

> minified js ... is trivially reversible

This is not true. Even if one forgets about stripped comments function and variable names in JS may provide essential clues to the programmer especially when programming in a function style with a lot of closures. In minified JS where the names are replaced with short 1-2 letters strings and functions are reordered to improve the level of compression with gzip the clues are gone and it could be very hard to understand the code even after pretty-printing it.

Minify vs Compression?

Posted Mar 15, 2013 16:04 UTC (Fri) by alex (subscriber, #1355) [Link]

Out of interest how much does the default gzip compression most web-servers apply to text reduce the size of jQuery? In effect minifying is just an obfuscating compression.

Minify vs Compression?

Posted Mar 15, 2013 16:14 UTC (Fri) by rfunk (subscriber, #4054) [Link]

I don't know if most web servers do compression by default; I've always seen it as an add-on, never already enabled out of the box.

But I just checked the same jQuery files with gzip... The 232k un-minified version compresses to 66k, while the 92k minified version compresses to 32k.

Minify vs Compression?

Posted Mar 15, 2013 16:25 UTC (Fri) by alex (subscriber, #1355) [Link]

I admit my sampling was rather unscientific being looking at Google and LWN headers, surprisingly the BBC front page isn't compressed at all (perhaps because some random old browser would barf).

However if sites are not enabling gzip they would get a bigger win by enabling gzip than by minifying their JavaScript although obviously if they do both they get the best bang-per-bandwidth bit.

Minify vs Compression?

Posted Mar 15, 2013 19:12 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]

enabling gzip with dynamic content adds a significant CPU load to the webservers. For a small site this may not matter, but for a large site, it's frequently cheaper to get the extra bandwith and send out the minified version uncompressed than to pay for the extra machines needed to enable gzip.

Minify vs Compression?

Posted Mar 18, 2013 16:05 UTC (Mon) by njwhite (subscriber, #51848) [Link]

But as this is regarding minification, we're talking about non-dynamic content anyway, right? So a site could (and many do) gzip their content just once.

Some frameworks offer on demand minification too (MediaWiki's ResourceLoader is the one I know), so technically minification can also be done for dynamic content, but as you say, it depends on where the bottlenecks are as to whether that's a wise move.

Javascript

Posted Mar 19, 2013 23:38 UTC (Tue) by bkuhn (subscriber, #58642) [Link]

And binary program distribution wasn't invented merely to obfuscate, but rather to make it so users didn't have to recompile all sources just to use a program. We already have a history of computing convenience, like Javascript minification, being used to impede software freedom. That's nothing new.

Sep	OCT	Nov
	17
2014	2015	2016