As much Stack Overflow as possible in 4096 bytes • Hacker News Board

Re: As much Stack Overflow as possible in 4096 bytes

#21

Post by baddox » Mon, Feb 17, 2014, 9:14 PM UTC

MasterScrat wrote: post #15

baddox wrote: post #5

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.

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.

Re: As much Stack Overflow as possible in 4096 bytes

#22

Post by thedufer » Mon, Feb 17, 2014, 9:15 PM UTC

dangayle wrote: post #17

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

There's a short list at the end of the post about Trello4k: http://danlec.com/blog/trello-in-4096-bytes

Re: As much Stack Overflow as possible in 4096 bytes

#23

Post by tedd4u » Mon, Feb 17, 2014, 9:24 PM UTC

afhof wrote: post #19

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.

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).

Re: As much Stack Overflow as possible in 4096 bytes

#24

Post by julian37 » Mon, Feb 17, 2014, 9:33 PM UTC

jc4p wrote: post #2

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

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_C...

Re: As much Stack Overflow as possible in 4096 bytes

#25

Post by shawabawa3 » Mon, Feb 17, 2014, 10:00 PM UTC

nandhp wrote: post #12

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

It's monospace for me (chrome windows 7)

Re: As much Stack Overflow as possible in 4096 bytes

#26

Post by lucian1900 » Mon, Feb 17, 2014, 10:02 PM UTC

baddox wrote: post #5

jc4p wrote: post #2

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

> - 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…

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.

Re: As much Stack Overflow as possible in 4096 bytes

#27

Post by aaronblohowiak » Mon, Feb 17, 2014, 10:17 PM UTC

deckiedan wrote: post #14

bane wrote: post #9

Earlier quoted context omitted.

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 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.

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 extreme…

the "sufficiently smart compiler" is kind of like "world peace"; something to work towards, but i doubt we'll have it this lifetime.

http://c2.com/cgi/wiki?SufficientlySmartCompiler

Re: As much Stack Overflow as possible in 4096 bytes

#28

Post by MasterScrat » Mon, Feb 17, 2014, 10:26 PM UTC

baddox wrote: post #21

MasterScrat wrote: post #15

Earlier quoted context omitted.

> 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.

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.

Actually that's what Google has done with 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.

Re: As much Stack Overflow as possible in 4096 bytes

#29

Post by SmileyKeith » Mon, Feb 17, 2014, 10:30 PM UTC

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.

Re: As much Stack Overflow as possible in 4096 bytes

#30

Post by dubcanada » Mon, Feb 17, 2014, 10:36 PM UTC

nandhp wrote: post #12

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 :)