Live data from Hacker News

As much Stack Overflow as possible in 4096 bytes

danlec.com

11–20 of 77 posts

Re: As much Stack Overflow as possible in 4096 bytes

#11
post #9
post #6

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

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.

[deleted]

Re: As much Stack Overflow as possible in 4096 bytes

#13
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/

[1]: https://github.com/pagespeed/ngx_pagespeed

edit: formatting

Re: As much Stack Overflow as possible in 4096 bytes

#14
post #9
post #6

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

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 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/ ) or something like that is heading in the right direction. 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.

Re: As much Stack Overflow as possible in 4096 bytes

#15
post #5
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…

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

Re: As much Stack Overflow as possible in 4096 bytes

#16
post #9
post #6

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

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.

There are examples of advanced functionality performing well enough. Google Docs is quite fast, especially for what it is.

On the other hand, there are sites which are conceptually much simpler but incredibly sluggish. Twitter is a particularly bad offender after you've scrolled down a few pages. Or any other site that uses a ton of Ajax with little regard for the consequences.

Re: As much Stack Overflow as possible in 4096 bytes

#18

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

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

Re: As much Stack Overflow as possible in 4096 bytes

#20
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?
Post reply on HN