4 ms·
Also wonder how many savings are still possible with a more efficient HTML/CSS/JS binary representation. Text is low tech and all but it still hurts to waste so
by RGamma 2y ago
Also wonder how many savings are still possible with a more efficient HTML/CSS/JS binary representation. Text is low tech and all but it still hurts to waste so many octets for such a relatively low amount of possible symbols.
Applies to all formal languages actually. 2^(8x20x10^6) ~= 2x10^48164799 is such a ridiculously large space...
- pgraf 2y agoShouldn’t HTTP compression reap most of the benefits of this approach for bigger pages?
- chris_pie 2y agoCheck this proposal out: https://github.com/tc39/proposal-binary-ast https://github.com/tc39/proposal-binary-ast
- jiggawatts 2y agoThe generalisation of this concept is what I like call the "kilobyte" rule. A typical web page of text on a screen is about a kilobyte. Sure, you can pack more in with fine print, and obviously additional data is required to represent the styling, but the actual text is about 1 kb. If you've sent 20 MB, then that is 20,000x more data than what was displayed on the screen. Worse still, an uncompressed 4K still image is only 23.7 megabytes. At some point you might be better off doing "server side rendering" with a GPU instead of sending more JavaScript!
- RGamma 2y agoSoo.. there should be a standardized web API for page content. And suddenly... gopher (with embedded media/widgets).
- Lex-2008 2y ago> "server side rendering" with a GPU instead of sending more JavaScript Some 7~10 years ago I remember I saw somewhere (maybe here on HN) a website which did exactly this: you gave it an URL - it downloaded a webpage with all its resources, rendered and screenshot'ed it (probably in headless Chrome or something), and compared size of png screenshot versus size of webpage with all its resources. For many popular websites, png screenshot of a page indeed was several times less than webpage itself!
- jcgrillo 2y agoIf your server renders the image as text we'll be right back down towards a kilobyte again. See https://www.brow.sh/ https://www.brow.sh/
- skydhash 2y agoI read epubs, and they’re mostly html and css files zipped. The whole book usually comes under a MB if there’s not a lot of big pictures. Then you come across a website and for just an article you have to download tens of MBs. Disable JavaScript and the website is broken.
- LtWorf 2y agoSurely you're aware of gzip encoding on the wire for http right?
- RGamma 2y agoSure, would be interesting to know how it would fare against purpose-made compression under real world conditions still...
- LtWorf 2y agogzip is fast. And it was made for real world conditions.
- floam 2y agoBrotli is a better example, as it was literally purpose made for HTML/CSS/JS. It is now supported basically everywhere for HTTP compression, and uses a huge custom dictionary (about 120KB) that was trained on simulated web traffic. You can even swap in your own shared dictionary with a HTTP header, but trying to make your own dictionary specific to your content is a fool’s errand, you’ll never amortize the cost in total bits. What you CAN do with shared dictionaries though, is delta updates. https://developer.chrome.com/blog/shared-dictionary-compression https://developer.chrome.com/blog/shared-dictionary-compress... https://news.ycombinator.com/item?id=39615198 https://news.ycombinator.com/item?id=39615198