51–60 of 77 posts
First off, nice work. I've noticed that St4k is loading each thread using ajax, where-as stackoverflow actually opens a new 'page', reloading a lot of webrequests. Disclaimer I've got browser cache disabled. E.g on a thread click: St4k: GET https://api.stackexchange.com/2.2/questions/21840919 [HTTP/1.1 200 OK 212ms] 18:02:16.802 GET https://www.gravatar.com/avatar/dca03295d2e81708823c5bd62e75... [HTTP/1.1 200 OK 146m…
Code is formatted in a serif font, instead of monospace, which seems like a rather important difference. Otherwise, it is quite impressive.
You most likely don't have Consolas, or Monaco then. That font family should have been Consolas,Monaco,monospace Rather then Consolas,Monaco,serif But what ever :)
$ curl -s http://danlec.com/st4k | gzip -cd | sed 's/serif/monospace/' | gzip -9c | wc
14 94 4098Did you try a png data url? Could be smaller.
$ zopfli -c st4k |wc
11 127 4050Some of the workarounds he mentions at the end of his Trello in 4096 bytes[1] post seem really interesting: - I optimized for compression by doing things the same way everywhere; e.g. I always put the class attribute first in my tags - I wrote a utility that tried rearranging my CSS, in an attempt to find the ordering that was the most compressible [1] http://danlec.com/blog/trello-in-4096-bytes
I've seen similar ideas in the demoscene 4k competition world, where code and music is arranged to have as many repeating self-similar patterns as possible so the executable compressors can shrink them optimally.
I would love to investigate this further. I've always had a suspicion that the aim to make everything reusable for the sake of bite size actually has the opposite effect, as you have to start writing in support and handling tons of edge cases as well, not to mention you now have to write unit test so anyone who consumes your work isn't burned by a refactor. Obviously, there's a place for things like underscore, jquery, and boilerplate code like Backbone, but bringing enterprise-level extensibility to client code is probably mostly a bad thing.
Wonder how we can unobfuscate the source. It would be great if there is a readable version of the source as well, just like we have in Obfuscated C Code Contests. Or perhaps, some way to use the Chrome inspector for this.
I'd take some trade-off between between crazy optimization and maintainability, but I'd definitely rather do this than slap on any number of frameworks because they are the new 'standard'.
Of course, the guy who has to maintain my code usually ends up crying like a little girl.
Looks broken on my Android mobile, but seriously this is incredible! Wonder how we can unobfuscate the source. It would be great if there is a readable version of the source as well, just like we have in Obfuscated C Code Contests. Or perhaps, some way to use the Chrome inspector for this.
Earlier quoted context omitted.
> - I optimized for compression by doing things the same way everywhere; e.g. I always put the class attribute first in my tags Compression algorithms can do a better job when they're domain-aware. An HTML-aware algorithm could compress HTML much better than a general-use plain-text compression algorithm, without requiring the user to do things like put the class attribute first. Of course, that also requires the de…
> that also requires the decompression algorithm to be similarly aware, which can be a problem if you're distributing the compressed bits widely. Well not necessarily... An HTML-aware algorithm could for example rearrange attributes in the same order everywhere because it knows it doesn't matter . Actually that would be a nice addition to the HTML "compressors" out there.
The reason for doing it wasn't so much the compression benefit but some of the nanoc code that generates the site did not always order the tags the same way and then it had to rsync up more than it needed to