>JavaScript today is capable of generating a lot of data. The easiest way to deliver multiple files to your users is in a zip file. Instead of wasting server resources and bandwidth you can get the client to do it for you.
... Am I not understanding what they're saying here or do the authors really not understand how the internet works?
It looks to me like they're saying "don't bother letting your users download zip files. Save your bandwidth! Just get them to send themselves a zip file, client-side!"
I'm guessing they mean some kind of situation where the resources you're zipping up have already been downloaded to the user's browser (like a "download as Zip" link for a set of images that are being displayed on the page).
In reality, I don't think there is a good use-case for this as any files that need to be zipped are likely too large for a user's browser to process with JS (it could bog down or crash the browser).
I have a feeling they already realize this though as the example zip file is 237 bytes. If an HTTP header is larger than your zipped file, it probably doesn't need to be zipped/gzipped in the first place.
Well, if you have a JS app, then it's likely the content the user wants to generate is already in their browser. So you could generate a zip locally and "download" it locally, without any network traffic at all.
It would be great for my current project. The project is entirely client-side right now, there is 0 server-side component (though certain features in the near future will require a server-side aspect). For what my project is doing, and for the various interpretations of what ZIP can be, having client-side ZIP generation is great.
Just think of all of the container formats that use ZIP with different file extensions. JAR and ePub to be two off the top of my head; I am sure there are plenty more.
The importance is not in compression, it is in container formats.
Hi, I'm the author of JSZip. This sentence is kind of awkward. What I meant is that a lot of data is generated in the browser, and traditionally (at least at the time I wrote this library almost 5 years ago) this would involve sending the data back to your server to zip it up and send it back to the user for download. Instead this can all be done client side.
As an example, someone told me about a web app[1] which allows you to create an animated sprite offline. They use JSZip to let you download all the frames in one file.
There's actually an outstanding PR[2] to update the documentation that I still need to review, hopefully that makes things clearer.
Consider something like bootstrap, which allows you to customize your download before sending you a zip file.
The assets are already loaded (since you're viewing the bootstrap demo page), so instead of making a request to another server to generate some sort of compressed file for you, that labor is offloaded to the client.
Except you're unnecessarily bogging down the user's browser to a far greater extent (base64 encoding/decoding everything on a possibly underpowered CPU/IO) than the amount of work it would take to do it on the server (pure binary processing on a high end CPU).
I'm guessing Bootstrap can do it because they know most Bootstrap users are developers with decent PCs but for a more mainstream audience, it would be problematic.
Have you used Mega.com? It does in-browser (JavaScript) encryption of uploads and downloads. And I can still hit 5 MB/s throughput. JavaScript can handle Zip compression easily.
For most users, bandwidth is in shorter supply than CPU. Especially on mobile (your constrained CPU/IO case), where people are using 3G or worse, which is often even billed by the MB.
Except that most clients are ridiculously overpowered compared to a heavily loaded server. Even the slowest 1.3ghz core 2 duo is better than a high end xeon if there are 10 users at one time.
It seems that the data to be zipped is also on the client side (e.g. a color scheme designer tool that wants to bundle some css files and a background image). If the alternative is sending the uncompressed data back to the server and having the server bundle them up into a zip, this approach saves bandwidth.
... Am I not understanding what they're saying here or do the authors really not understand how the internet works?
It looks to me like they're saying "don't bother letting your users download zip files. Save your bandwidth! Just get them to send themselves a zip file, client-side!"