4 ms·

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 i

by pippy 11y ago

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.

austinheap 11y ago
Isn't that mostly moot with HTTP 2.0 multiplexing?
- discreditable 11y ago
  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.
lukeman 11y ago
Couldn't you use inline scripts and styles with images specified as data uris?
- bosdev 11y ago
  Yes, I've used bundlers before which package the scripts and styles into a single HTML file.
- dheera 11y ago
  Data URLs for large images are horribly space-inefficient.
  - kevincox 11y ago
    Once you gzip them they aren't bad.
    - kbenson 11y ago
      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.
  - ghayes 11y ago
    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 https://en.wikipedia.org/wiki/Base64#MIME
    - dheera 11y ago
      Right, I miscalculated, Base64 isn't as bad as I thought.
tantalor 11y ago
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.
seanp2k2 11y ago
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-side-rendered-javascript-apps/ http://tomdale.net/2015/02/youre-missing-the-point-of-server...
- LukeShu 11y ago
  Flash programs could start running before the whole things was downloaded. Hence custom loading bars on flash movies on Newgrounds.
spankalee 11y ago
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.
glass55 11y ago
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)
mintplant 11y ago
WARC, maybe? http://bibnum.bnf.fr/WARC/ http://bibnum.bnf.fr/WARC/
- greglindahl 11y ago
  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.
munchbunny 11y ago
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.
kalleboo 11y ago
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 https://en.wikipedia.org/wiki/MHTML

by pippy 11y ago

austinheap 11y ago

Isn't that mostly moot with HTTP 2.0 multiplexing?

discreditable 11y ago
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.

lukeman 11y ago

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

bosdev 11y ago
Yes, I've used bundlers before which package the scripts and styles into a single HTML file.
dheera 11y ago
Data URLs for large images are horribly space-inefficient.
- kevincox 11y ago
  Once you gzip them they aren't bad.
  - kbenson 11y ago
    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.
- ghayes 11y ago
  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 https://en.wikipedia.org/wiki/Base64#MIME
  - dheera 11y ago
    Right, I miscalculated, Base64 isn't as bad as I thought.

tantalor 11y ago

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.

seanp2k2 11y ago

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-side-rendered-javascript-apps/ http://tomdale.net/2015/02/youre-missing-the-point-of-server...

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

spankalee 11y ago

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.

glass55 11y ago

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)

mintplant 11y ago

WARC, maybe? http://bibnum.bnf.fr/WARC/ http://bibnum.bnf.fr/WARC/

greglindahl 11y ago
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.

munchbunny 11y ago

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.

kalleboo 11y ago

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 https://en.wikipedia.org/wiki/MHTML