8 ms·

As much Stack Overflow as possible in 4096 bytes

382 points by df07 13y ago

jc4p 13y ago
Some 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 http://danlec.com/blog/trello-in-4096-bytes
- baddox 13y ago
  > - 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 decompression algorithm to be similarly aware, which can be a problem if you're distributing the compressed bits widely.
  - MasterScrat 13y ago
    > 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.
    - baddox 13y ago
      That's a good point. You could have an HTML-aware "precompressor" prepare the HTML for a general-use compression algorithm. However, with end-to-end HTML awareness I think you could do even better.
      - MasterScrat 13y ago
        Actually that's what Google has done with Courgette: http://www.chromium.org/developers/design-documents/software-updates-courgette http://www.chromium.org/developers/design-documents/software... > Courgette transforms the input into an alternate form where binary diffing is more effective, does the differential compression in the transformed space, and inverts the transform to get the patched output in the original format. With careful choice of the alternate format we can get substantially smaller updates.
    - speleding 13y ago
      I actually do just that with a pre-processor on my site, it's only a single line of ruby with a regex, a split, a sort and a join. 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
  - lucian1900 13y ago
    What that means in practice is a binary encoding, which would be really nice. At least HTTP is getting a sane binary encoding, hopefully more protocols/formats will follow.
- julian37 13y ago
  On a related note, Google Closure Compiler has some optimizations that increase code size before compression in order to achieve gains after compression. http://code.google.com/p/closure-compiler/wiki/FAQ#Closure_Compiler_inlined_all_my_strings,_which_made_my_code_size http://code.google.com/p/closure-compiler/wiki/FAQ#Closure_C...
- nulagrithom 13y ago
  After browsing St4koverflow for a while, the amount of time it took to load the Trello auth screen was jarring. I could get used to that kind of speed.
- bane 13y ago
  It sounds like the goal was to reduce the entropy of the code as much as possible, to within whatever the windows of the algorithm were set to. 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.
  - pointernil 13y ago
    ...and reordering vertex data in chunks of only x-coords followed by chunks of y-coords followed by z-coords for the same reasons. "Farbrausch" and their series of Fr-X "small" demos would be one example of this kind of "entropy trickery" http://www.pouet.net/groups.php?which=322 http://www.pouet.net/groups.php?which=322 The next target for crunching would be to minimize the actual amount of code given to the browser to execute, versus maximizing the compression ratio only (which is "just" correlated to the running "code" size)
jonalmeida 13y ago
Pages load almost instantly like as if it's a local webserver - I'm quite impressed.
nej 13y ago
Wow navigating around feels instant and it almost feels as if I'm hosting the site locally. Great job!
mberning 13y ago
Very impressive. I wish extreme performance goals and requirements would become a new trend. I think we have come to accept a certain level of sluggishness in web apps. I hate it. I wrote a tire search app a few years back and made it work extremely fast given the task at hand. But I did not go to the level that this guy did. http://tiredb.com http://tiredb.com
- bane 13y ago
  Now that we have blisteringly fast computers, it's worth it to browse old websites and see what "snappy" looks like. http://info.cern.ch/hypertext/WWW/TheProject.html http://info.cern.ch/hypertext/WWW/TheProject.html If we could cram more modern functionality into say...twice or three times the performance of the above, I think the web would be a better place. Instead the web is a couple orders of magnitude slower.
  - deleted 13y ago
    [deleted]
  - deckiedan 13y ago
    Yes. In some ways I think we're still in a very primative kind of level for web development. Either you do it by hand, tweaking each individual parameter like the old demoscene, and making it fast and amazingly small, or else you write huge chunky slow web apps, or more usually, something in the middle. I feel like the big thing I'm missing is smart compilers that can take web app concepts, and turn them into extremely optimsed 'raw' HTML/CSS/JS/SQL/backend. All of the current frameworks still use hand written frequently very bloated or inelegant hand written CSS & HTML, and still require thinking manually about how and when to do AJAX when it's least offensive to the user. Maybe something like yesod ( http://www.yesodweb.com/ http://www.yesodweb.com/ ) or something like that is heading in the right direction. http://pyjs.org/ http://pyjs.org/ has some nice ideas too... But I'm thinking of something bigger than the individual technologies like coffeescript or LESS... Something that doesn't 'compile to JS', or 'compile to CSS', but 'compile to stack'. I dunno. Maybe I'm just rambling.
    - 13y ago
jpatel3 13y ago
Way to go!
nathancahill 13y ago
This is really fast! Love it. I thought the real site was fast until I clicked around on this.
blazespin 13y ago
Very impressive! So incredibly fast. My only thoughts are that search is the real bottleneck.
nandhp 13y ago
Code is formatted in a serif font, instead of monospace, which seems like a rather important difference. Otherwise, it is quite impressive.
- shawabawa3 13y ago
  It's monospace for me (chrome windows 7)
- dubcanada 13y ago
  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 :)
  - timtadh 13y ago
    Yep: but fixing breaks the 4096 barrier: $ curl -s http://danlec.com/st4k | gzip -cd | sed 's/serif/monospace/' | gzip -9c | wc 14 94 4098
- netghost 13y ago
  If you're using Chrome, there's a bug in recent versions that seems to butcher font rendering at random. Try popping open the inspector panel, and the fonts will magically correct themselves.
Whitespace 13y ago
I'm curious if a lot of the customizations re:compression could be similarly achieved if the author used Google's modpagespeed for apache[0] or nginx[1], as it does a lot of these things automatically including eliding css/html attributes and generally re-arranging things for optimal sizes. It could make writing for 4k less of a chore? In any case, this is an outstanding hack. The company I work for has TLS certificates that are larger than the payload of his page. Absolutely terrific job, Daniel. [0]: https://code.google.com/p/modpagespeed/ https://code.google.com/p/modpagespeed/ [1]: https://github.com/pagespeed/ngx_pagespeed https://github.com/pagespeed/ngx_pagespeed edit: formatting
- lstamour 13y ago
  Well, the TLS problem is why we'd also want QUIC. But that's another story...
dangayle 13y ago
I'd love to see a general list of techniques you use, as best practices.
- thedufer 13y ago
  There's a short list at the end of the post about Trello4k: http://danlec.com/blog/trello-in-4096-bytes http://danlec.com/blog/trello-in-4096-bytes
  - dangayle 13y ago
    Thanks. How much of that could we do during the original design phase?
afhof 13y ago
4096 is a good goal, but there is a much more obvious benefit at 1024 since it would fit within the IPv6 1280 MTU (i.e. a single packet). I recall hearing stories that the Google Homepage had to fit within 512 bytes for IPv4's 576 MTU.
- tedd4u 13y ago
  One packet is great if you can do it. There's a big penalty after the sender in a new TCP connection reaches the initial transmit window. A lot of sites these days have configured this up from 2x or 3x MSS to 10x MSS (about 5,360 bytes) to increase what can be sent in the first transmission back from the server (HTTP response for example).
  - Dylan16807 13y ago
    If they're configured for 10x they're probably also going to be using an MSS of 1460, so you can cram 14 kilobytes of data into the initial request.
Jakob 13y ago
I didn’t realize that the original site is already quite optimized. With a primed cache the original homepage results in only one request: html ~200KB (~33 gzipped) Not bad at all. Of course the 4k example is even more stunning. Could the gzip compression best practices perhaps be added to an extension like mod_pagespeed?
SmileyKeith 13y ago
This is amazing. As others have said I really wish this kind of insane performance would be a goal for sites like this. After trying this demo I found it difficult to go back to the same pages on the normal site. Also I imagine even with server costs this would save them a lot of bandwidth.
derefr 13y ago
> I threw DRY out the window, and instead went with RYRYRY. Turns out just saying the same things over and over compresses better than making reusable functions This probably says something about compression technology vs. the state of the art in machine learning, but I'm not sure what.
cobookman 13y ago
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 https://api.stackexchange.com/2.2/questions/21840919 [HTTP/1.1 200 OK 212ms] 18:02:16.802 GET https://www.gravatar.com/avatar/dca03295d2e81708823c5bd62e752121 https://www.gravatar.com/avatar/dca03295d2e81708823c5bd62e75... [HTTP/1.1 200 OK 146ms] 18:02:16.803 stackoverflow.com (a lot of web requests): GET http://stackoverflow.com/questions/21841027/override-volume-button-in-background-service http://stackoverflow.com/questions/21841027/override-volume-... [HTTP/1.1 200 OK 120ms] 18:02:54.791 GET http://ajax.googleapis.com/ajax/libs/jquery/1.7.1/jquery.min.js http://ajax.googleapis.com/ajax/libs/jquery/1.7.1/jquery.min... [HTTP/1.1 200 OK 62ms] 18:02:54.792 GET http://cdn.sstatic.net/Js/stub.en.js http://cdn.sstatic.net/Js/stub.en.js [HTTP/1.1 200 OK 58ms] 18:02:54.792 GET http://cdn.sstatic.net/stackoverflow/all.css http://cdn.sstatic.net/stackoverflow/all.css [HTTP/1.1 200 OK 73ms] 18:02:54.792 GET https://www.gravatar.com/avatar/2a4cbc9da2ce334d7a5c8f483c9216e1 https://www.gravatar.com/avatar/2a4cbc9da2ce334d7a5c8f483c92... [HTTP/1.1 200 OK 90ms] 18:02:55.683 GET http://i.stack.imgur.com/tKsDb.png http://i.stack.imgur.com/tKsDb.png [HTTP/1.1 200 OK 20ms] 18:02:55.683 GET http://static.adzerk.net/ados.js http://static.adzerk.net/ados.js [HTTP/1.1 200 OK 33ms] 18:02:55.684 GET http://www.google-analytics.com/analytics.js http://www.google-analytics.com/analytics.js [HTTP/1.1 200 OK 18ms] 18:02:55.684 GET http://edge.quantserve.com/quant.js http://edge.quantserve.com/quant.js ....and more....
- deleted 13y ago
  [deleted]
- oneeyedpigeon 13y ago
  Almost all that really tells us is that you have browser cache disabled (resources such as jquery wouldn't be re-requested on StackOverflow is you didn't). As a matter of interest, why are you disabling browser cache? Doesn't that waste a needless amount of bandwidth? Is it for some kind of security reason?
  - cobookman 13y ago
iamdanfox 13y ago
The simpler UI is quite pleasant to use isn't it! I wonder if companies would benefit from holding internal '4096-challenges'?
masswerk 13y ago
And now consider that 4096 bytes (words) was exactly the total memory of a DEC PDP-1, considered to be a mainframe in its time and featuring timesharing and things like Spacewar!. And now we're proud to have a simple functional list compiled into the same amount of memory ...
- rangibaby 13y ago
  Your iPhone also had more computing power than the rest of the world. Combined! :-)
  - masswerk 13y ago
    And it even can play Bach and connect to the network, like the PDP-1! :-)
stefan_kendall 13y ago
Maybe part of the story here is that gzip isn't the be-all-end-all of compression. A lot of the changes were made to appease the compression algorithm; seems like the algorithm could change to handle the input. A specialized compression protocol for the web?
TacticalCoder 13y ago
In a different style, the "Elevated" demo, coded in 4K (you'll have a hard time believing it if you haven't seen it yet): http://www.youtube.com/watch?v=_YWMGuh15nE http://www.youtube.com/watch?v=_YWMGuh15nE
deleted 13y ago
[deleted]
deleted 13y ago
[deleted]
timtadh 13y ago
funny, his compressor must do a better job than mine: $ curl -s http://danlec.com/st4k | wc 14 80 4096 $ curl -s http://danlec.com/st4k | gzip -cd | wc 17 311 11547 $ curl -s http://danlec.com/st4k | gzip -cd | gzip -c | wc 19 103 4098
- bdonlan 13y ago
  Turn up the compression level: $ curl -s http://danlec.com/st4k | gzip -cd | gzip -9c | wc 14 80 4096
  - timtadh 13y ago
    Right. I feel silly for not trying that. Good spot.
tantalor 13y ago
> The stackoverflow logo is embedded? Did you try a png data url? Could be smaller.
scoopr 13y ago
There seems to be many bytes left! :) $ zopfli -c st4k |wc 11 127 4050
- slackito 13y ago
  Thanks for the pointer to zopfli. I've used p7zip in the past as a "better gzip", and it gets good results for this one too :D $ curl -s http://danlec.com/st4k | gzip -cd | 7z a -si -tgzip -mx=9 compressed.gz $ wc compressed.gz 14 84 4048 compressed.gz
dclowd9901 13y ago
>"I threw DRY out the window, and instead went with RYRYRY. Turns out just saying the same things over and over compresses better than making reusable functions" 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.
arocks 13y ago
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.
- rangibaby 13y ago
  Using HTML prettify on the source is a start at least: https://github.com/victorporof/Sublime-HTMLPrettify https://github.com/victorporof/Sublime-HTMLPrettify
kislayverma 13y ago
Very very awesome. 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.
shdon 13y ago
His root element is "<html dl>". I'm not aware of the dl attribute even existing... Is that for compressibility or does the "dl" actually do something?
jazzdev 13y ago
Impressive, and a useful exercise, but it doesn't seem practical to give up DRY in favor of RYRYRY just because it compresses better and saves a few bytes.

382 points by df07 13y ago

jc4p 13y ago

Some 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 http://danlec.com/blog/trello-in-4096-bytes

baddox 13y ago
> - 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 decompression algorithm to be similarly aware, which can be a problem if you're distributing the compressed bits widely.
- MasterScrat 13y ago
  > 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.
  - baddox 13y ago
    That's a good point. You could have an HTML-aware "precompressor" prepare the HTML for a general-use compression algorithm. However, with end-to-end HTML awareness I think you could do even better.
    - MasterScrat 13y ago
      Actually that's what Google has done with Courgette: http://www.chromium.org/developers/design-documents/software-updates-courgette http://www.chromium.org/developers/design-documents/software... > Courgette transforms the input into an alternate form where binary diffing is more effective, does the differential compression in the transformed space, and inverts the transform to get the patched output in the original format. With careful choice of the alternate format we can get substantially smaller updates.
  - speleding 13y ago
    I actually do just that with a pre-processor on my site, it's only a single line of ruby with a regex, a split, a sort and a join. 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
- lucian1900 13y ago
  What that means in practice is a binary encoding, which would be really nice. At least HTTP is getting a sane binary encoding, hopefully more protocols/formats will follow.
julian37 13y ago
On a related note, Google Closure Compiler has some optimizations that increase code size before compression in order to achieve gains after compression. http://code.google.com/p/closure-compiler/wiki/FAQ#Closure_Compiler_inlined_all_my_strings,_which_made_my_code_size http://code.google.com/p/closure-compiler/wiki/FAQ#Closure_C...
nulagrithom 13y ago
After browsing St4koverflow for a while, the amount of time it took to load the Trello auth screen was jarring. I could get used to that kind of speed.
bane 13y ago
It sounds like the goal was to reduce the entropy of the code as much as possible, to within whatever the windows of the algorithm were set to. 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.
- pointernil 13y ago
  ...and reordering vertex data in chunks of only x-coords followed by chunks of y-coords followed by z-coords for the same reasons. "Farbrausch" and their series of Fr-X "small" demos would be one example of this kind of "entropy trickery" http://www.pouet.net/groups.php?which=322 http://www.pouet.net/groups.php?which=322 The next target for crunching would be to minimize the actual amount of code given to the browser to execute, versus maximizing the compression ratio only (which is "just" correlated to the running "code" size)

jonalmeida 13y ago

Pages load almost instantly like as if it's a local webserver - I'm quite impressed.

nej 13y ago

Wow navigating around feels instant and it almost feels as if I'm hosting the site locally. Great job!

mberning 13y ago

Very impressive. I wish extreme performance goals and requirements would become a new trend. I think we have come to accept a certain level of sluggishness in web apps. I hate it. I wrote a tire search app a few years back and made it work extremely fast given the task at hand. But I did not go to the level that this guy did. http://tiredb.com http://tiredb.com

bane 13y ago
Now that we have blisteringly fast computers, it's worth it to browse old websites and see what "snappy" looks like. http://info.cern.ch/hypertext/WWW/TheProject.html http://info.cern.ch/hypertext/WWW/TheProject.html If we could cram more modern functionality into say...twice or three times the performance of the above, I think the web would be a better place. Instead the web is a couple orders of magnitude slower.
- deleted 13y ago
  [deleted]
- deckiedan 13y ago
  Yes. In some ways I think we're still in a very primative kind of level for web development. Either you do it by hand, tweaking each individual parameter like the old demoscene, and making it fast and amazingly small, or else you write huge chunky slow web apps, or more usually, something in the middle. I feel like the big thing I'm missing is smart compilers that can take web app concepts, and turn them into extremely optimsed 'raw' HTML/CSS/JS/SQL/backend. All of the current frameworks still use hand written frequently very bloated or inelegant hand written CSS & HTML, and still require thinking manually about how and when to do AJAX when it's least offensive to the user. Maybe something like yesod ( http://www.yesodweb.com/ http://www.yesodweb.com/ ) or something like that is heading in the right direction. http://pyjs.org/ http://pyjs.org/ has some nice ideas too... But I'm thinking of something bigger than the individual technologies like coffeescript or LESS... Something that doesn't 'compile to JS', or 'compile to CSS', but 'compile to stack'. I dunno. Maybe I'm just rambling.
  - 13y ago

jpatel3 13y ago

Way to go!

nathancahill 13y ago

This is really fast! Love it. I thought the real site was fast until I clicked around on this.

blazespin 13y ago

Very impressive! So incredibly fast. My only thoughts are that search is the real bottleneck.

nandhp 13y ago

Code is formatted in a serif font, instead of monospace, which seems like a rather important difference. Otherwise, it is quite impressive.

shawabawa3 13y ago
It's monospace for me (chrome windows 7)
dubcanada 13y ago
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 :)
- timtadh 13y ago
  Yep: but fixing breaks the 4096 barrier: $ curl -s http://danlec.com/st4k | gzip -cd | sed 's/serif/monospace/' | gzip -9c | wc 14 94 4098
netghost 13y ago
If you're using Chrome, there's a bug in recent versions that seems to butcher font rendering at random. Try popping open the inspector panel, and the fonts will magically correct themselves.

Whitespace 13y ago

I'm curious if a lot of the customizations re:compression could be similarly achieved if the author used Google's modpagespeed for apache[0] or nginx[1], as it does a lot of these things automatically including eliding css/html attributes and generally re-arranging things for optimal sizes. It could make writing for 4k less of a chore? In any case, this is an outstanding hack. The company I work for has TLS certificates that are larger than the payload of his page. Absolutely terrific job, Daniel. [0]: https://code.google.com/p/modpagespeed/ https://code.google.com/p/modpagespeed/ [1]: https://github.com/pagespeed/ngx_pagespeed https://github.com/pagespeed/ngx_pagespeed edit: formatting

lstamour 13y ago
Well, the TLS problem is why we'd also want QUIC. But that's another story...

dangayle 13y ago

I'd love to see a general list of techniques you use, as best practices.

thedufer 13y ago
There's a short list at the end of the post about Trello4k: http://danlec.com/blog/trello-in-4096-bytes http://danlec.com/blog/trello-in-4096-bytes
- dangayle 13y ago
  Thanks. How much of that could we do during the original design phase?

afhof 13y ago

4096 is a good goal, but there is a much more obvious benefit at 1024 since it would fit within the IPv6 1280 MTU (i.e. a single packet). I recall hearing stories that the Google Homepage had to fit within 512 bytes for IPv4's 576 MTU.

tedd4u 13y ago
One packet is great if you can do it. There's a big penalty after the sender in a new TCP connection reaches the initial transmit window. A lot of sites these days have configured this up from 2x or 3x MSS to 10x MSS (about 5,360 bytes) to increase what can be sent in the first transmission back from the server (HTTP response for example).
- Dylan16807 13y ago
  If they're configured for 10x they're probably also going to be using an MSS of 1460, so you can cram 14 kilobytes of data into the initial request.

Jakob 13y ago

I didn’t realize that the original site is already quite optimized. With a primed cache the original homepage results in only one request: html ~200KB (~33 gzipped) Not bad at all. Of course the 4k example is even more stunning. Could the gzip compression best practices perhaps be added to an extension like mod_pagespeed?

SmileyKeith 13y ago

This is amazing. As others have said I really wish this kind of insane performance would be a goal for sites like this. After trying this demo I found it difficult to go back to the same pages on the normal site. Also I imagine even with server costs this would save them a lot of bandwidth.

derefr 13y ago

> I threw DRY out the window, and instead went with RYRYRY. Turns out just saying the same things over and over compresses better than making reusable functions This probably says something about compression technology vs. the state of the art in machine learning, but I'm not sure what.

cobookman 13y ago

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 https://api.stackexchange.com/2.2/questions/21840919 [HTTP/1.1 200 OK 212ms] 18:02:16.802 GET https://www.gravatar.com/avatar/dca03295d2e81708823c5bd62e752121 https://www.gravatar.com/avatar/dca03295d2e81708823c5bd62e75... [HTTP/1.1 200 OK 146ms] 18:02:16.803 stackoverflow.com (a lot of web requests): GET http://stackoverflow.com/questions/21841027/override-volume-button-in-background-service http://stackoverflow.com/questions/21841027/override-volume-... [HTTP/1.1 200 OK 120ms] 18:02:54.791 GET http://ajax.googleapis.com/ajax/libs/jquery/1.7.1/jquery.min.js http://ajax.googleapis.com/ajax/libs/jquery/1.7.1/jquery.min... [HTTP/1.1 200 OK 62ms] 18:02:54.792 GET http://cdn.sstatic.net/Js/stub.en.js http://cdn.sstatic.net/Js/stub.en.js [HTTP/1.1 200 OK 58ms] 18:02:54.792 GET http://cdn.sstatic.net/stackoverflow/all.css http://cdn.sstatic.net/stackoverflow/all.css [HTTP/1.1 200 OK 73ms] 18:02:54.792 GET https://www.gravatar.com/avatar/2a4cbc9da2ce334d7a5c8f483c9216e1 https://www.gravatar.com/avatar/2a4cbc9da2ce334d7a5c8f483c92... [HTTP/1.1 200 OK 90ms] 18:02:55.683 GET http://i.stack.imgur.com/tKsDb.png http://i.stack.imgur.com/tKsDb.png [HTTP/1.1 200 OK 20ms] 18:02:55.683 GET http://static.adzerk.net/ados.js http://static.adzerk.net/ados.js [HTTP/1.1 200 OK 33ms] 18:02:55.684 GET http://www.google-analytics.com/analytics.js http://www.google-analytics.com/analytics.js [HTTP/1.1 200 OK 18ms] 18:02:55.684 GET http://edge.quantserve.com/quant.js http://edge.quantserve.com/quant.js ....and more....

deleted 13y ago
[deleted]
oneeyedpigeon 13y ago
Almost all that really tells us is that you have browser cache disabled (resources such as jquery wouldn't be re-requested on StackOverflow is you didn't). As a matter of interest, why are you disabling browser cache? Doesn't that waste a needless amount of bandwidth? Is it for some kind of security reason?
- cobookman 13y ago

iamdanfox 13y ago

The simpler UI is quite pleasant to use isn't it! I wonder if companies would benefit from holding internal '4096-challenges'?

masswerk 13y ago

And now consider that 4096 bytes (words) was exactly the total memory of a DEC PDP-1, considered to be a mainframe in its time and featuring timesharing and things like Spacewar!. And now we're proud to have a simple functional list compiled into the same amount of memory ...

rangibaby 13y ago
Your iPhone also had more computing power than the rest of the world. Combined! :-)
- masswerk 13y ago
  And it even can play Bach and connect to the network, like the PDP-1! :-)

stefan_kendall 13y ago

Maybe part of the story here is that gzip isn't the be-all-end-all of compression. A lot of the changes were made to appease the compression algorithm; seems like the algorithm could change to handle the input. A specialized compression protocol for the web?

TacticalCoder 13y ago

In a different style, the "Elevated" demo, coded in 4K (you'll have a hard time believing it if you haven't seen it yet): http://www.youtube.com/watch?v=_YWMGuh15nE http://www.youtube.com/watch?v=_YWMGuh15nE

deleted 13y ago

[deleted]

deleted 13y ago

[deleted]

timtadh 13y ago

bdonlan 13y ago
Turn up the compression level: $ curl -s http://danlec.com/st4k | gzip -cd | gzip -9c | wc 14 80 4096
- timtadh 13y ago
  Right. I feel silly for not trying that. Good spot.

tantalor 13y ago

> The stackoverflow logo is embedded? Did you try a png data url? Could be smaller.

scoopr 13y ago

There seems to be many bytes left! :) $ zopfli -c st4k |wc 11 127 4050

slackito 13y ago
Thanks for the pointer to zopfli. I've used p7zip in the past as a "better gzip", and it gets good results for this one too :D $ curl -s http://danlec.com/st4k | gzip -cd | 7z a -si -tgzip -mx=9 compressed.gz $ wc compressed.gz 14 84 4048 compressed.gz

dclowd9901 13y ago

>"I threw DRY out the window, and instead went with RYRYRY. Turns out just saying the same things over and over compresses better than making reusable functions" 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.

arocks 13y ago

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.

rangibaby 13y ago
Using HTML prettify on the source is a start at least: https://github.com/victorporof/Sublime-HTMLPrettify https://github.com/victorporof/Sublime-HTMLPrettify

kislayverma 13y ago

Very very awesome. 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.

shdon 13y ago

His root element is "<html dl>". I'm not aware of the dl attribute even existing... Is that for compressibility or does the "dl" actually do something?

jazzdev 13y ago

Impressive, and a useful exercise, but it doesn't seem practical to give up DRY in favor of RYRYRY just because it compresses better and saves a few bytes.