I tried JSZip not too long ago for my side project and it was quite slow. I've been using http://gildas-lormeau.github.io/zip.js/ and I'm very happy with it. I hope to release my web app some time this week.
JSZip: Create, read and edit .zip files with JavaScript
41–50 of 57 posts
Re: JSZip: Create, read and edit .zip files with JavaScript
#42Potential use case: instead of using CSS sprite maps (putting all of your images into one image to reduce the number of http requests generated by your page, then using css magic to select regions inside of that image), image files could be zipped into an image package that is delivered to the client, who unzips it and uses the images inside. This would cut down on the number of requests made, but allow the images to…
So is the point to simplify the process or something else? 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.
CSS Sprites have numerous disadvantages that normal image files lack.
Re: JSZip: Create, read and edit .zip files with JavaScript
#43Earlier quoted context omitted.
i'm surprised we don't have a cross-browser webarchive concept yet... especially with the emphasis on mobile.
We have a fantastic one based on MIME that is usable by everything except Firefox (however you need to enable some experimental stuff in Chrome). http://en.wikipedia.org/wiki/MHTML
Until now I always thought the M stood for Microsoft. Now I know.
Re: JSZip: Create, read and edit .zip files with JavaScript
#44I tried JSZip not too long ago for my side project and it was quite slow. I've been using http://gildas-lormeau.github.io/zip.js/ and I'm very happy with it. I hope to release my web app some time this week.
zip.js seems to be the better of the two. It uses typed arrays, so it's performant and I can zip large (140MB) files quickly and without hanging the browser.
Re: JSZip: Create, read and edit .zip files with JavaScript
#45We use jszip for parsing xlsx/xlsm/xlsb files in the browser (Excel 2007+ files are zip files that contain XML or binary files in specific locations): https://github.com/SheetJS/js-xlsx JSZip works well for small files, but unzipping XLSB files larger than 50M seem to cause out of memory issues in Firefox
Have you considered zip.js instead? It claims to work with files up to 4GB. It also can zip large files without any issues for me in Firefox.
Re: JSZip: Create, read and edit .zip files with JavaScript
#46Potential use case: instead of using CSS sprite maps (putting all of your images into one image to reduce the number of http requests generated by your page, then using css magic to select regions inside of that image), image files could be zipped into an image package that is delivered to the client, who unzips it and uses the images inside. This would cut down on the number of requests made, but allow the images to…
The crazy thing: in this thread, you are all right. The state of sending multiple files sucks. ZIP is the closest thing we have to a universal standard, if only because Windows refuses to ship with support for anything that is meaningful.
Well, is there anything better for Windows, aside from maybe cabinet files?
Re: JSZip: Create, read and edit .zip files with JavaScript
#47This is exactly a project I was about to embark upon to generate ePub files from client-side JS. Thanks!
Interesting - can I ask what you're working on? I'd be a bit worried about potentially memory issues with image-heavy ePubs.
A minimalist writing tool to train beginner novelists on completing writing projects: https://www.justwritedammit.com/#main/about
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.
Re: JSZip: Create, read and edit .zip files with JavaScript
#48Why not unrar and untar using javascript as well?
Re: JSZip: Create, read and edit .zip files with JavaScript
#49It's really fast at reading zip files created by Google takeout. I use it at http://theyhaveyour.info as it works perfectly with the FileReader API. For reading only though - haven't tried writing with it.
Re: JSZip: Create, read and edit .zip files with JavaScript
#50Earlier quoted context omitted.
Some images formats already come with compression. Also, zip doesn't work with well with binary data. Using CSS to "subscript" into the sprite is a better solution.
It's not about saving bandwidth or space by compressing the images - it's about removing the step of combining your images into one big image then using coordinates inside of that image to find your original images. 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 wi…
> 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).