Re: [FileAPI] Revisiting Deflate/Compression

I agree, the available libraries that currently exists not only are
slow compared to native code (I don't know of anyone that use the
trick used on the demos scene of canvas.getasbytestring() ) and to
speed up things they use webworkers, so they are difficult to use from
file:// scheme pages.

2013/7/13 Charles Pritchard <>:
> We've had a few conversations pop up about exposing deflate/inflate to the
> webapps environment.
> Years of them (more recently May 2013).
> Packaging a zip file is very simple in JS, it's just the inflate/deflate
> code that's a trudge.
> We all know the benefits of compressing JSON and XML over the pipe.
> I'd like to see deflate exposed through FileReader.
> For example: reader.readAsArrayBuffer(blob, {deflate: true});
> Inflate semantics could be similar:
> reader.readAsArrayBuffer(blob, {inflate: true});
> Being that blob is synchronous, it seems like extending the constructor
> would only be reasonable in the context of a worker:
> new Blob(["my easily compressed string...."], {deflate: true});
> Jonas already outlined some of the reasons not to pursue this:
> inflate/deflate can be performed in JS, JS is reasonably fast...
> In practice, JS is significantly slower than the browser's own native code,
> native code is already available in existing browsers, there are very few
> deflate/inflate JS libraries available, and including them has costs in
> size, loading time and licensing. As a consequence, web app authors are
> simply not using deflate when appropriate. We can easily remedy that by
> exposing deflate and inflate through these existing APIs.
> If there is push-back on extending Blob, I'm content with simply getting
> FileReader to support inflate/deflate.
> -Charles

"Si quieres viajar alrededor del mundo y ser invitado a hablar en un
monton de sitios diferentes, simplemente escribe un sistema operativo
 Linus Tordvals, creador del sistema operativo Linux

Received on Monday, 15 July 2013 07:29:05 UTC