gildas

You can have a look at the last 2 examples here [1].

[1] https://github.com/gildas-lormeau/single-file-cli?tab=readme...

Thanks a lot! Believe me, there have been a lot of bugs (+900 issues closed today) because it's hard to save a web page actually. You were lucky not to suffer ;)

You can find a comparison of file formats here: https://github.com/gildas-lormeau/SingleFile?tab=readme-ov-f...

Author of SingleFile here, one of the major differences is that monolith doesn't use a web browser to take page captures. As a result, it doesn't support JavaScript, for example. SingleFile, on the other hand, requires a Chromium-based browser to be installed. It should also produce smaller pages and is capable of generating ZIP or self-extracting ZIP files. However, it will take longer to capture a page. Note that since version 2, it is now possible to download executable files of the CLI tool [1].

[1] https://github.com/gildas-lormeau/single-file-cli/releases

You could download SingleFile [1], configure a WebDAV server in the options page (cf. "Destination" section), and set up Joplin to synchronize with the server.

[1] https://github.com/gildas-lormeau/SingleFile

You should try SingleFile, see https://github.com/gildas-lormeau/SingleFile

Thank you very much for your support! I've just read your post about SingleFile and Obsidian [1]. I'm glad to see that you've managed to integrate SingleFile perfectly into your workflow :)

[1] https://vertis.io/2024/01/26/how-singlefile-transformed-my-o...

Unfortunately, the file poses a problem for basic unzipping software (e.g. a file explorer). However, the file is 100% valid with respect to the ZIP specification. You just need to use "true" unzipping software like 7zip, unzip etc. to read it as such.

The index page is protected via CSP. The "bootstrap" page which unzips the page isn't but it could. I just did not include it for some reasons I've forgotten.

The JS is not essential, there's nothing to stop you treating the file as a ZIP file and unzipping it beforehand to view it.

> 5. Finally, just distribute it in a zip file. That's how ebooks already work right?

What about self-extracting ZIP files like this page? https://gildas-lormeau.github.io/ (note that it includes the CSP to make it safe)

Actually, the first release of SingleFile is 13+ years old but it was less popular at the time because Chrome (it didn't yet support MHTML) had a negligible market share. People generally saved their pages in MAFF or MHTML format in Firefox or IE. It was when Firefox abandoned XUL extensions that SingleFile was able to rise from the ashes, because there was once again a real interest in it.

Thank you for trusting me and for your kind words ;)

Author here, I wished SingleFile would use less permissions, but it's unforntunately not possible from a technical point of view. Anyway, if you run some code I've written but are suspicious, you have to trust me or review the code which is open-source.

Here is an example of my ideal self-contained document format [1]. It's a self-extracting ZIP which can also be read as a PNG image.

[1] https://gildas-lormeau.github.io/

You can save pages a self-extracting pages to produce compact pages, see [1].

[1] https://gildas-lormeau.github.io/singlefile-updates/version-....

Thank you for the feedback. Actually it's the result of a PoC based on SingleFile [1] which can already saved pages as self-extracting ZIP [2]. The innovation is the integration of the screenshot in PNG format.

[1] https://github.com/gildas-lormeau/SingleFile

[2] https://github.com/gildas-lormeau/SingleFile/blob/master/faq...

As the founder of SEO4Ajax, I can assure you that this is far from the case. Googlebot, for example, still has great difficulty indexing dynamically generated JavaScript content on the client side.

It's a kind of demo of SingleFile and the self-extracting ZIP format [1]. The self-extracting ZIP format is an improvement when you want to archive web pages and read them without relying on an extension. The fact that resources are compressed also considerably reduces archive size.

I agree it would be "great" a complete website in the ZIP. I think this is technically possible, someone just have to code it.

[1] https://github.com/gildas-lormeau/SingleFile#singlefile

Mine is not a WASM file but is a ZIP file, see https://gildas-lormeau.github.io/

Shameless plug, my homepage on GitHub is also one binary (self-extracting ZIP) file which run on client-side, see https://gildas-lormeau.github.io/

It looks like these websites are in a whitelist, see https://blog.google/products/chrome/improving-autoplay-chrom...

Alternatively, when formatted "properly", you can also simply host your zip file. See https://gildas-lormeau.github.io/ for example.

Similarly, for zipping files in JS, I have coded the possibility to compress zip files on several cores in zip.js [1]. The approach is simpler as it consists of compressing the entries in parallel. It still offers a significant performance gain though when compressing multiple files in a zip file, which is often the nominal case.

[1] https://github.com/gildas-lormeau/zip.js

Options 1 and 3 are implemented.

Please read the documentation of the API and you might think the probability would be very low [1]. Note also that zip.js works totally fine in all stable browsers, Safari 16.4 included. There are no known issues [2]. I have absolutely no idea what we are talking about because it looks like the bug has been fixed by Apple in the stable version of Safari. And maybe zip.js helped them to do so.

[1] https://developer.mozilla.org/en-US/docs/Web/API/Compression...

[2] https://github.com/gildas-lormeau/zip.js/issues

It was hard for me to anticipate that Apple would implement the CompressionStream API incorrectly 6 months later. However, it is extremely likely that an exception was indeed raised when this bug was triggered. I was never made aware of the existence of this bug. Besides, zip.js does its best to rely on fallback implementations in case of errors. I'm not supposed to integrate the entire CompressionStream API test suite (and all the other APIs) into zip.js either.

Author of zip.js here, the CompressionStream API is available for 3 years in Chromium-based browsers [1]. That's why I integrated it 6 months ago in zip.js. However zip.js can detect if the API is present or not, and can work if not available (e.g. in Firefox). It cannot detect implementation bugs in the API though. Note that there's also an option to disable the use of the API [2].

[1] https://caniuse.com/?search=CompressionStream

[2] https://gildas-lormeau.github.io/zip.js/api/interfaces/Confi...

You can do the same thing with SingleFileZ [1] which can protect saved pages with a password. It relies on the zip specification to store the encrypted resources (html, images, css, etc.).

Here's an example of protected page saved with SingleFileZ: https://gildas-lormeau.github.io/private/ (password: thisisapage)

[1] https://github.com/gildas-lormeau/SingleFileZ

You might prefer SingleFileZ, see https://github.com/gildas-lormeau/SingleFileZ

It looks like they're also downloading images directly from your domain, I see https://www.saashub.com/images/app/service_logos/129/k2q4pxz... for example in my debugger.

Edit: you could maybe add a <meta> tag to define a CSP in but I guess they will remove it [1].

[1] https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP