Will this work with multi-gigabyte files?

[ThiefMaster]

I have a feature in my application where one can generate pretty large ZIP files (let's say many slides for presentations from a conference) - those archives can easily be multiple gigabytes large. To reduce the load on the server I'm looking into options to build them client-side, and this library seems to be a nice choice.

But I wonder if there are any browser limitations for this, because unlike with a regular download this library would start downloading large amounts of data from the server before even showing the user a download prompt (I think). So where are those stored? Is the browser using its usual temporary storage that it also uses when starting a download until you pick the location / confirm that you want to download it? Are they stored in RAM?

Also, I'm not completely sure of if/when a service worker is needed (I'd prefer to avoid having to use one) with this library...

[Touffy]

Yes.

I'm afraid the ServiceWorker is very much needed in your use case*. That's what allows streaming the archive to the client — as shown in the Service Worker demo —, there will be no need to store anything much in the browser, no matter how big the archive will be in the end. The archive will be generated no faster than the user's filesystem can store it. That's where the archive will be stored : the filesystem. Outside of the browser.

Also there will be no undue latency. The Response is returned immediately when calling downloadZip, without waiting for the contents. The user will see the download being as soon as they click the link. If you can provide enough metadata in the options, there will even be a definite progress bar in the download manager.

*there is actually a way to stream to the filesystem without using the Service Worker : the Filesystem API's showSaveFilePicker method gives you a writable file handler that you can stream into directly. It's very nice, but not yet supported in Safari.

[ThiefMaster]

*there is actually a way to stream to the filesystem without using the Service Worker : the Filesystem API's showSaveFilePicker method gives you a writable file handler that you can stream into directly. It's very nice, but not yet supported in Safari

Not being supported by Firefox is the bigger issue IMHO ;)

[Touffy]

You can check the performance (memory, speed and latency) on this live demo by supplying URLs for publicly (and CORS-enabled) accessible resources.