decompress brotli in browser? #11

Closed
opened 2026-01-29 20:28:43 +00:00 by claunia · 19 comments
Owner

Originally created by @jedie on GitHub (Jun 26, 2015).

Is there a JavaScript Implementation of the decompressor part for in browser usage?

I found https://github.com/devongovett/brotli.js and created https://github.com/devongovett/brotli.js/issues/2 ... but maybe someone else knows a decompress implementation?

Originally created by @jedie on GitHub (Jun 26, 2015). Is there a JavaScript Implementation of the decompressor part for in browser usage? I found https://github.com/devongovett/brotli.js and created https://github.com/devongovett/brotli.js/issues/2 ... but maybe someone else knows a decompress implementation?
Author
Owner

@candrew34 commented on GitHub (Sep 24, 2015):

I am looking for the same thing.

@candrew34 commented on GitHub (Sep 24, 2015): I am looking for the same thing.
Author
Owner

@eustas commented on GitHub (Oct 6, 2015):

Hello.

"brotli" content-encoding support has been recently added to Firefox 44.
In Chromium project there is also intent to support brotli content-encoding.

When done will make decoding fast and transparent for developers.
As a fallback, you could transpile brotli to JavaScript, for example, using Emscripten.
I'll add more details how to do it soon.

@eustas commented on GitHub (Oct 6, 2015): Hello. "brotli" content-encoding support has been recently added to Firefox 44. In Chromium project there is also intent to support brotli content-encoding. When done will make decoding fast and transparent for developers. As a fallback, you could transpile brotli to JavaScript, for example, using Emscripten. I'll add more details how to do it soon.
Author
Owner

@eustas commented on GitHub (Oct 7, 2015):

Quick tests with emscripten has shown that generated js code is 9 times slower on Firefox and about 14 times slower on Chrome.

@eustas commented on GitHub (Oct 7, 2015): Quick tests with emscripten has shown that generated js code is 9 times slower on Firefox and about 14 times slower on Chrome.
Author
Owner

@LifeIsStrange commented on GitHub (Oct 22, 2015):

Hello, there is also this rust library : https://github.com/ende76/compression
Which will be used by servo the layout engine of the future, see: https://github.com/servo/servo/issues/8156
:)

@LifeIsStrange commented on GitHub (Oct 22, 2015): Hello, there is also this rust library : https://github.com/ende76/compression Which will be used by servo the layout engine of the future, see: https://github.com/servo/servo/issues/8156 :)
Author
Owner

@eustas commented on GitHub (Oct 22, 2015):

Nice!
Thank you =)

@eustas commented on GitHub (Oct 22, 2015): Nice! Thank you =)
Author
Owner

@LifeIsStrange commented on GitHub (Oct 22, 2015):

You're welcome ! =)
Also are you a Firefox dev ? Because it will be more intelligent to use this rust library as a common gecko and servo library instead of duplicate the work in two distinct library ;) now that gecko can have rust code.
Also sorry for my poor english.

@LifeIsStrange commented on GitHub (Oct 22, 2015): You're welcome ! =) Also are you a Firefox dev ? Because it will be more intelligent to use this rust library as a common gecko and servo library instead of duplicate the work in two distinct library ;) now that gecko can have rust code. Also sorry for my poor english.
Author
Owner

@replete commented on GitHub (Dec 1, 2015):

I have a demo working here.

@replete commented on GitHub (Dec 1, 2015): I have a [demo working here](http://replete.github.io/brotli-experiments/).
Author
Owner

@devongovett commented on GitHub (Mar 28, 2016):

brotli.js (linked in the original issue) now has a hand ported decoder instead of using Emscripten. It is less than half the size of the Emscripten JS output, and is over twice as fast according to my benchmarks. To use in the browser, you can build it with Browserify or similar.

@devongovett commented on GitHub (Mar 28, 2016): [brotli.js](https://github.com/devongovett/brotli.js) (linked in the original issue) now has a hand ported decoder instead of using Emscripten. It is less than half the size of the Emscripten JS output, and is over twice as fast according to my benchmarks. To use in the browser, you can build it with Browserify or similar.
Author
Owner

@eustas commented on GitHub (Jun 21, 2016):

Added link to brotli.js in README.md

@eustas commented on GitHub (Jun 21, 2016): Added link to brotli.js in README.md
Author
Owner

@eustas commented on GitHub (Jul 31, 2017):

JS decoder transpiled from Java decoder is coming soon.

@eustas commented on GitHub (Jul 31, 2017): JS decoder transpiled from Java decoder is coming soon.
Author
Owner

@eustas commented on GitHub (Jul 31, 2017):

Perhaps even AsmJS, if it will give reasonable performance boost.

@eustas commented on GitHub (Jul 31, 2017): Perhaps even AsmJS, if it will give reasonable performance boost.
Author
Owner

@eustas commented on GitHub (Aug 28, 2017):

It turns out that AsmJs speed varies a lot from browser to browser. Pure JS decodes is performant enough for practical usage, it is ~2.x times faster than brotli.js and 5 times faster than BrotliHaxe/JS.

@eustas commented on GitHub (Aug 28, 2017): It turns out that AsmJs speed varies a lot from browser to browser. Pure JS decodes is performant enough for practical usage, it is ~2.x times faster than brotli.js and 5 times faster than BrotliHaxe/JS.
Author
Owner

@devongovett commented on GitHub (Aug 28, 2017):

@eustas brotli.js is pure JS, hand ported (at least the decoder). I found it to be ~2x faster than an emscripten compile of the C++ code when I wrote it, and much smaller. Am I understanding correctly that your new JS decoder is 2x faster again than brotli.js (so 4x faster than emscripten)?

@devongovett commented on GitHub (Aug 28, 2017): @eustas brotli.js is pure JS, hand ported (at least the decoder). I found it to be ~2x faster than an emscripten compile of the C++ code when I wrote it, and much smaller. Am I understanding correctly that your new JS decoder is 2x faster again than brotli.js (so 4x faster than emscripten)?
Author
Owner

@eustas commented on GitHub (Aug 29, 2017):

Here is my playground: decoders.zip

  • alice.br - test file I've used for benchmarks
  • bar.html - AsmJS decoder transpiled from Java
  • bjs.html - brotli.js browserified
  • haxe.html - BrotliHaxe/JS
  • xxx.html - WebAssembly generated for C decoder with Emscripten
  • yyy.html - JS decoder transpiled from Java (and published in last commit)

AsmJs generated with Emscripten has nearly the same performance/structure/drawbacks as WebAssembly, so I've stopped experimenting with it.

@eustas commented on GitHub (Aug 29, 2017): Here is my playground: [decoders.zip](https://github.com/google/brotli/files/1259608/decoders.zip) * `alice.br` - test file I've used for benchmarks * `bar.html` - AsmJS decoder transpiled from Java * `bjs.html` - brotli.js browserified * `haxe.html` - BrotliHaxe/JS * `xxx.html` - WebAssembly generated for C decoder with Emscripten * `yyy.html` - JS decoder transpiled from Java (and published in last commit) AsmJs generated with Emscripten has nearly the same performance/structure/drawbacks as WebAssembly, so I've stopped experimenting with it.
Author
Owner

@v-python commented on GitHub (Jul 1, 2020):

What's the "warmup" business for yyy? Does it have to be done? Does it affect the timing? Seems yyy starts off slow but gets faster. I guess that happens for the others too... JIT JIT I guess.

xxx no longer works in Firefox if it ever did. haxe seems to hang after prompting for a file.

This is an interesting study, has it been updated?

Surprising that the browsers don't expose their internal decompression algorithms in a form useful to javascript, to avoid everyone loading other copies, wasting space and time.

@v-python commented on GitHub (Jul 1, 2020): What's the "warmup" business for yyy? Does it have to be done? Does it affect the timing? Seems yyy starts off slow but gets faster. I guess that happens for the others too... JIT JIT I guess. xxx no longer works in Firefox if it ever did. haxe seems to hang after prompting for a file. This is an interesting study, has it been updated? Surprising that the browsers don't expose their internal decompression algorithms in a form useful to javascript, to avoid everyone loading other copies, wasting space and time.
Author
Owner

@eustas commented on GitHub (Jul 2, 2020):

Yes, that is sad. It is known that every modern browser contains gzip encoder (for png from canvas), gzip and brotli decoder... Unfortunately, adding things to "web platform" is a bureaucracy hell...
Lets hope https://wicg.github.io/compression/ is the first step to make native codecs available...

@eustas commented on GitHub (Jul 2, 2020): Yes, that is sad. It is known that every modern browser contains gzip encoder (for png from canvas), gzip and brotli decoder... Unfortunately, adding things to "web platform" is a bureaucracy hell... Lets hope https://wicg.github.io/compression/ is the first step to make native codecs available...
Author
Owner

@LifeIsStrange commented on GitHub (Jul 2, 2020):

@eustas I can testify as for the "bureaucracy" hell..
I advocated to chromium deceloppers to include ZSTD (the successor to the antic gzip) to the spec you linked. Of course it was rejected for ridiculous justifications like it would be too hard for firefox to include zstandard and they assumed this without asking any mozilla dev on the matter...

Unrelated:
Chromium has shipped support for SIMD in webassembly
https://www.chromestatus.com/feature/6533147810332672
I guess that this is the future for decoders not in the browser

@LifeIsStrange commented on GitHub (Jul 2, 2020): @eustas I can testify as for the "bureaucracy" hell.. I advocated to chromium deceloppers to include ZSTD (the successor to the antic gzip) to the spec you linked. Of course it was rejected for ridiculous justifications like it would be too hard for firefox to include zstandard and they assumed this without asking any mozilla dev on the matter... Unrelated: Chromium has shipped support for SIMD in webassembly https://www.chromestatus.com/feature/6533147810332672 I guess that this is the future for decoders not in the browser
Author
Owner

@eustas commented on GitHub (Jul 2, 2020):

While WebAssembly is a nice idea, there is a long path to maturity for it. E.g. I've examined its performance for another codec (https://github.com/google/brunsli) and found that it is quite different of different platforms and browsers. It is nearly native on desktop, but on Android / arm it is 2x slower than native activity (https://bugs.chromium.org/p/chromium/issues/detail?id=1075947&q=reporter%3Ame&can=2)

Also, while I developed WASM SIMD code I have found a lot of bugs - llvm crashers, WASM crashers, incorrect behaviour... Currently it is much better - almost usable =)

@eustas commented on GitHub (Jul 2, 2020): While WebAssembly is a nice idea, there is a long path to maturity for it. E.g. I've examined its performance for another codec (https://github.com/google/brunsli) and found that it is quite different of different platforms and browsers. It is nearly native on desktop, but on Android / arm it is 2x slower than native activity (https://bugs.chromium.org/p/chromium/issues/detail?id=1075947&q=reporter%3Ame&can=2) Also, while I developed WASM SIMD code I have found a lot of bugs - llvm crashers, WASM crashers, incorrect behaviour... Currently it is much better - almost usable =)
Author
Owner

@sylarlin commented on GitHub (Apr 15, 2022):

Here is my playground: decoders.zip

  • alice.br - test file I've used for benchmarks
  • bar.html - AsmJS decoder transpiled from Java
  • bjs.html - brotli.js browserified
  • haxe.html - BrotliHaxe/JS
  • xxx.html - WebAssembly generated for C decoder with Emscripten
  • yyy.html - JS decoder transpiled from Java (and published in last commit)

AsmJs generated with Emscripten has nearly the same performance/structure/drawbacks as WebAssembly, so I've stopped experimenting with it.

@eustas nice work!!!
Im looking for a single js file version of brotli decoder. That helps me alot. Espcecially bar.js file in the decoders.zip.
But it seems that they all transpiled from the lower version of brotli.
Could you pls upgrade the bar.js to the latest version(1.0.9)?
Or could you pls tell me how to transpile from java to asmjs (not wasm in our scenario). I have googled all round but failed.😢
Any hints would be very appreciated!!!
Best regards!!!

@sylarlin commented on GitHub (Apr 15, 2022): > Here is my playground: [decoders.zip](https://github.com/google/brotli/files/1259608/decoders.zip) > > * `alice.br` - test file I've used for benchmarks > * `bar.html` - AsmJS decoder transpiled from Java > * `bjs.html` - brotli.js browserified > * `haxe.html` - BrotliHaxe/JS > * `xxx.html` - WebAssembly generated for C decoder with Emscripten > * `yyy.html` - JS decoder transpiled from Java (and published in last commit) > > AsmJs generated with Emscripten has nearly the same performance/structure/drawbacks as WebAssembly, so I've stopped experimenting with it. @eustas nice work!!! Im looking for a single js file version of brotli decoder. That helps me alot. Espcecially bar.js file in the [decoders.zip](https://github.com/google/brotli/files/1259608/decoders.zip). But it seems that they all transpiled from the lower version of brotli. Could you pls upgrade the bar.js to the latest version(1.0.9)? Or could you pls tell me how to transpile from java to asmjs (not wasm in our scenario). I have googled all round but failed.😢 Any hints would be very appreciated!!! Best regards!!!
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/brotli#11