Hacker News Reader

Comment by pippy | Hacker News Reader

One thing HTML5 lacks is the ability to combine all assets into one file. This makes Flash particularly handy for advertisements. Safari almost got there with its .Webarchive format, and Mozilla experimented with a file format but it didn't get anywhere.

View on HN

Bundles might make sense, but one large blob that couldn't be parsed until it was finished loading would probably be a big step backward for responsiveness. Parallel downloads also help speed things up.

Another interesting idea for JS-heavy sites is server-side pre rendering (yes, having the server generate HTML like the good old bad days) like Ember FastBoot http://tomdale.net/2015/02/youre-missing-the-point-of-server...

Flash programs could start running before the whole things was downloaded. Hence custom loading bars on flash movies on Newgrounds.

HTML Imports basically give you bundling, at least for CSS, JS, markup, and things you can fit into data URLs. It'd be awesome to explore how HTML can serve as a better bundling format for ES2015 modules and generic files like video.

Isn't that mostly moot with HTTP 2.0 multiplexing?

Almost. Compressing all of the files into one archive often results in a smaller file overall. This might work a little differently with brotli, which uses a precomputed dictionary.

The advantage of keeping the files separate is that it allows for procedural rendering. Multiplexing gives this a boost by allowing your client to fetch a lot of files at the same time.

Couldn't you use inline scripts and styles with images specified as data uris?

Yes, I've used bundlers before which package the scripts and styles into a single HTML file.

Data URLs for large images are horribly space-inefficient.

Once you gzip them they aren't bad.

We've been down the rabbit hole for a while now, and we've decided it's not so bad down here. Now we are browsing for curtains and a good rug to make the place feel more like home.

Data URLs should be ~1.37x the size [0] of the original file (and generally, kept in the same format). Obviously, there are issues of caching, keeping the image loaded in memory, etc, but it shouldn't be all that bad. Esp. when you consider that ads are inefficient for a variety of other reasons.

[0] https://en.wikipedia.org/wiki/Base64#MIME

Right, I miscalculated, Base64 isn't as bad as I thought.

Google more or less invented the .adz file for that. It's a glorified zip file with a few naming conventions and a few other things. Many of the more common pieces of ad serving software support it.

This is from the perspective of the person who is uploading the ad, of course, not from the perspective of the browser that is downloading the ad later.

Another old format in that space is/was MHTML - a MIME document with all the resources needed for a webpage. https://en.wikipedia.org/wiki/MHTML

You could encode assets using "base64" and put everything in a single JS file. There may be a file size issue though, but I did that a few times (actually I did that with html files using data uris)

WARC, maybe?

http://bibnum.bnf.fr/WARC/

WARC has proven to be useful in web archiving contexts, I'd love to see browsers use it for good. http/2 is headed in a quite different direction already.

Doesn't seem like it would be very difficult to parse a zip file from a typed array (fetched with binary Xhr) and pull out images files, video files, etc. This has probably already been done but I can't find a project presently.

Reply on news.ycombinator.com