Pretty cool. I made something similar (much more hacky) a while ago: https://github.com/AdrianVollmer/Zundler
Works locally, but it does need to decompress everything first thing.
Pretty cool. I made something similar (much more hacky) a while ago: https://github.com/AdrianVollmer/Zundler
Works locally, but it does need to decompress everything first thing.
So this is like SingleFileZ in that it's a single static inefficient HTML archive, but it can easily be viewed locally as well?
How does it bypass the security restrictions which break SingleFileZ/Gwtar in local viewing mode? It's complex enough I'm not following where the trick is and you only mention single-origin with regard to a minor detail (forms).
The content is in an iframe, my code is outside of it, and the two frames are passing messages back and forth. Also I'm monkey patching `fetch` and a few other things.
OK, but how does that get you 'efficiency' if you're doing this weird thing where you serialize the entire page into some JSON blob and pass it in to an iframe or whatever? That would seem to destroy the 'efficiency' property of the trilemma. How do you get the full set of single-file, static, and efficient, while still working locally?
I suppose it's not efficient in that sense. As I said, the browser has to unpack the whole thing first, so you see a spinner when opening large files. But it's inserted into the DOM on demand, so it's not overwhelming the browser because it's just a blob in memory.
OK, so your format doesn't solve the trilemma; you have 'static' and 'single-file', but not 'efficient'. Seems like you might as well just go with MHT or SingleFile then...?