new | show | ask | jobs Github

etiquette 2 days ago

> A real food-delivery page - markup, images & an SVG animation in one .hmml, 30% smaller than the same page as base64

Why the comparison with Base64 when Base64 itself has approximately 33% size overhead?

▲ yeargun 2 days ago | parent [-]

A: I want to serve html with images all in single pack

You have 2 options.

- Embed images into html (base64, size overhead)

- embed html/css/js into media binaries

.hmml is the packing strategy for option two. 2kb js for encode/decode. And extra rantings around what a 'digital image' is

▲ sltkr 2 days ago | parent | next [-]

If you compress the HTML, which you want to do anyway for HTML/CSS if you care about file sizes, then most of the base64 overhead goes away:

    $ head -c 1000000 /dev/urandom | base64 -w0 | gzip | wc -c
    1009042

    $ head -c 1000000 /dev/urandom | base64 -w0 | zstd | wc -c
    1000300

So gzipped base64 can add less than 1% overhead. Of course a binary format can be even more efficient (also when decoding, I imagine) but the question is if the difference is big enough to introduce an entirely new format when base64 data URIs are already widely supported.

Then the other question is why this proposed packed format is better than the dozen already existing formats like Web Archive, CHM, MAFF, MHTML, etc.

▲ gildas 2 days ago | parent | prev [-]

There is a third option:

- Save the page as a self-extracting ZIP file, see https://github.com/gildas-lormeau/Polyglot-HTML-ZIP-PNG

	▲	yeargun 2 days ago \| parent [-]
		GGs on the library .hmml might be more hassle free then zip options for web apps. With zips, I think it will require more js bundle & processing to work. meanwhile with .hmml, its already gzip/br compressed in cdns, and decoded natively by the browser