The smallest JavaScript libraries on the internet
minime.stephan-brumme.com
minime.stephan-brumme.com
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.
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-...
Wonder if they'll make a CoffeeScript wrapper soon.
Thanks for the tip!
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.
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.
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
<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.