I'm wondering for some time if the minification could be done in a way that would help the gzipping achieve better ratios.
For example if you have to minified function and one has three local variables and the other two it might be beneficial to minify it as "var a, b;var c;" if there are a lot of functions with two parameters a only one with 3. Or always assign "this" to a variable called "t" so that "t=this" (or "var t=this;") is repeated often.
This seems to be low hanging fruit but there is a lot of microoptimizations like that even if it saves <5% like this brute forcing it might be worthwhile.
A new compression algorithm from Google, which is already used for web-fonts. Currently usable in Chrome & Firefox.
Replacing deflate with brotli typically gives an increase of 20% in compression density for text files, while compression and decompression speeds are roughly unchanged
Scroll down to the bottom of each page (e.g. http://minime.stephan-brumme.com/jquery/2.2.0/ ). There you will find a comparison of the major non-DEFLATE algorithms, such as Brotli, RAR, 7z, xz, bzip2.
Why do these JS framework comparison articles never include http://vanilla-js.com/ ? It's all the new rage, and has these other contenders beat every time when both post- and pre- compression.
> Why do these JS framework comparison articles never include http://vanilla-js.com/ ? It's all the new rage, and has these other contenders beat every time when both post- and pre- compression.
A JS framework is vanilla-js by definition. What you people fail to understand is the difference between a language (Javascript) and an API (the DOM). There is no DOM by default with Node. It would be stupid to say that Node isn't vanilla-js. Someone who is using jQuery is (obviously) using vanilla-js. People who can't tell the difference are the ones that should be mocked, not the ones using a framework because it's convenient. So please go read the javascript spec and educate yourselves about what javascript is.
> So please go read the javascript spec and educate yourselves about what javascript is.
That I can always do but sadly, developing a sense of humor for a healthy dose of lighthearted self-deprecation will pose a far more difficult challenge for many HN readers.
Is the time taken to decompress these minified libraries identical to the original minified libraries? Be nice to see if there was a measurement on that.
I clearly understand they don't want to waste hours on compression. But why don't they even achieve the level of a simple gzip -6 (default level) ?
Especially Microsoft's CDN is very bad in this category.
Do you have any evidence that these smaller files stress the client CPU more (this is probably not an absurd statement, but I claim that one can only make serious discussions about this point if one has a computable (i.e. not only empirically measurable) metric that measures how much a client CPU is stressed by some file).
> Do you have any evidence that these smaller files stress the client CPU more (this is probably not an absurd statement, but I claim that one can only make serious discussions about this point if one has a computable (i.e. not only empirically measurable) metric that measures how much a client CPU is stressed by some file).
http://tukaani.org/lzma/benchmarks.html, Actually I was wrong, Gzip decompression doesn't seem to be impacted at all by higher compression rate, it's even the reverse with small gain in decompression speed. Gzip compression is though - for a mere 3% to 5% gain in size, compression is taking 4x to 6x the time.
> proxy caching is harder, could you explain me the reason for that?
The tricky part is each filed can be compressed in different ways, the CDN might have to store different versions of the same file that can lead to a mismatch between the compression used and the actual compression of the file, a good post on the topic: https://www.maxcdn.com/blog/accept-encoding-its-vary-importa... It's doable but it's not trivial.
That's true for commercial CDNs. However, these Javascript libraries are hosted on free (!) CDNs, such as those kindly provided by Google, Microsoft, etc.
Author here: my website isn't about Javascript in the first place, it's about compression.
I could have done something similar with PNGs, PDFs or ZIPs (same DEFLATE compression algorithm) but Javascript is much more widespread.
In the browser I always end up with a ') at the top of all my pages. I'm assuming this is because the script tag actually closes inside of the document.write instead of the actual end. Am I the only one with this issue? Not sure what went wrong here.
25 comments
[ 3.1 ms ] story [ 64.1 ms ] threadFor example if you have to minified function and one has three local variables and the other two it might be beneficial to minify it as "var a, b;var c;" if there are a lot of functions with two parameters a only one with 3. Or always assign "this" to a variable called "t" so that "t=this" (or "var t=this;") is repeated often.
This seems to be low hanging fruit but there is a lot of microoptimizations like that even if it saves <5% like this brute forcing it might be worthwhile.
It also reminds me of Stack Overflow in 4096 bytes [2], where author also tried to write code that would compress more.
[1] https://github.com/google/closure-compiler/wiki/FAQ#closure-...
[2] http://danlec.com/blog/stackoverflow-in-4096-bytes
A new compression algorithm from Google, which is already used for web-fonts. Currently usable in Chrome & Firefox.
Replacing deflate with brotli typically gives an increase of 20% in compression density for text files, while compression and decompression speeds are roughly unchanged
A JS framework is vanilla-js by definition. What you people fail to understand is the difference between a language (Javascript) and an API (the DOM). There is no DOM by default with Node. It would be stupid to say that Node isn't vanilla-js. Someone who is using jQuery is (obviously) using vanilla-js. People who can't tell the difference are the ones that should be mocked, not the ones using a framework because it's convenient. So please go read the javascript spec and educate yourselves about what javascript is.
That I can always do but sadly, developing a sense of humor for a healthy dose of lighthearted self-deprecation will pose a far more difficult challenge for many HN readers.
Wonder if they'll make a CoffeeScript wrapper soon.
Thanks for the tip!
I think CDNs have a good reason for choosing their preferred method of compression. Just the file size alone isn't the whole picture.
Do you have any evidence that these smaller files stress the client CPU more (this is probably not an absurd statement, but I claim that one can only make serious discussions about this point if one has a computable (i.e. not only empirically measurable) metric that measures how much a client CPU is stressed by some file).
* proxy caching is harder
Could you explain me the reason for that?
http://tukaani.org/lzma/benchmarks.html, Actually I was wrong, Gzip decompression doesn't seem to be impacted at all by higher compression rate, it's even the reverse with small gain in decompression speed. Gzip compression is though - for a mere 3% to 5% gain in size, compression is taking 4x to 6x the time.
> proxy caching is harder, could you explain me the reason for that?
The tricky part is each filed can be compressed in different ways, the CDN might have to store different versions of the same file that can lead to a mismatch between the compression used and the actual compression of the file, a good post on the topic: https://www.maxcdn.com/blog/accept-encoding-its-vary-importa... It's doable but it's not trivial.
<script>window.jQuery || document.write('<script src="local_server_path/jquery.min.js"></script>')</script>
In the browser I always end up with a ') at the top of all my pages. I'm assuming this is because the script tag actually closes inside of the document.write instead of the actual end. Am I the only one with this issue? Not sure what went wrong here.