JSZip: Create, read and edit .zip files with JavaScript
stuk.github.io
stuk.github.io
JSZip works well for small files, but unzipping XLSB files larger than 50M seem to cause out of memory issues in Firefox
You may want to take a look at the master branch, because we've recently updated our inflate/deflate implementation to use the much faster Pako, https://github.com/nodeca/pako
Sure, you can build the spriting into your build process, but I don't know how to do that (I'm sure there are tools) and you can't exactly use normal css since the coordinates of your images may change within the sprite sheet.
Using the zip method saves you some of that headache/overhead with the tradeoff of having to package your images into a zip and unzip them on the client side.
I wrote an NPM module recently using this exact technique, https://github.com/deathcap/artpacks (for use in the browser with browserify). Had a bunch of small textures, originally I was requesting each individually in their own HTTP request, but zipping them up and extracting in the browser led to a fairly significant improvement in latency.
Packing all of the small textures into one big image and slicing it up at runtime was also an option I considered. In fact, since I'm using these textures with WebGL they actually are packed into one large texture atlas before uploading to the GPU, then indexed at runtime using UV coordinates. So one could stitch together all the textures beforehand, distributing a prebuilt texture atlas as a single file over HTTP — this may slightly improve performance, but it has another disadvantage.
Flexibility. For my purposes, it makes more sense to build up the atlas dynamically at runtime, since you might not know exactly what textures are needed and when (due to the nature of my application). Also, I wanted to support "cascading" textures, where multiple packs are loaded each providing possibly a subset of all textures, and the first pack with a matching texture takes priority. With unzipping at runtime in the browser, this technique was very easy to implement (without the latency cost of individual texture file requests).
And for compatibility with img src, and other HTML file references, I just convert the unzipped file to an HTML5 Blob then request its 'blob:' URI. 'data:' URIs would also work, but blobs are widely supported by modern browsers (unlike 'filesystem:' URLs, for the Web Filesystem API supported by Chrome) and don't need to encode the full file contents in the URL. The complete process, including unzipping, matching, blobbing, all happens fairly fast, have not ran into any noticeable performance issues.
(Note: technically I'm not using Stuart Knightley's JSZip, but Kris Kowal's zip module https://www.npmjs.org/package/zip - I can't recall why as they are both available on NPM, but its the same idea).
CSS Sprites are very easy to make and use. You just need to set the right coordinates for the background-image.
On the other hand, running a complicated JS library and building an infrastructure to extract these images seems like an overkill for something that CSS sprites can do so easily.
Is PSZIp better?
BTW, here is how I make files download with the filename that I want: https://github.com/capnmidnight/JWD/blob/master/html5/deskto...
The call to the "a" function on line 8 is just generating an HTML anchor tag. You should be able to figure it out from there.
I'm specifically targeting novelists (at least, right now), so pictures and complex layouts shouldn't be an issue. I want it to be something you can easily pick up, plod away through, maybe pay someone to do some editing for you, and then walk you through pushing it out on the Amazon Kindle Store.
... 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!"
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.
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.
It's 2014 now. Your iphone is 10 times faster than your 1998 pentium 2. Even with the JS vm penalty.
Unless you're zipping 70mb files, there's no chance you're overwhelming anyone's browser.
The usecase for this is the same you'd have for any desktop application: A handy "binary file format" library. Data portability wins.
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.
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.
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.
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.
[1] http://www.piskelapp.com/ [2] https://github.com/Stuk/jszip/pull/114
This way, if you, say, want to take a part of the program and use it elsewhere, you have the advantage of the same language. If you want to ask a question about the program, you can count on other people knowing the language. If you want to illustrate something using a program, you have a common ground here.