Is there a particular reason there is no support for Brotli, bzip2 and LZMA2?

[gajus]

I am surprised that there isn't even an open ticket for the feature request.

Would a PR be accepted for either of these algorithms?

(...or is there a reason that makes performing this operation at Node.js-level a bad idea?)

Brotli in particular has a wide (58%) browser adoption http://caniuse.com/#search=Brotli

[gajus]

Oh, I see. There is an open issue for Brotli.

#71

[dougwilson]

Hi @gajus I know you closed the issue, but wanted to respond anyhow :) The main reason there is no support currently is because this module (like all of Express) tries to provide a "hassle-free" experience of installation. Effectively this means no dependencies on native modules, as this is still quite the hassle for Windows users (though it has been getting better). That limits the module to the algorithms that are bundled into Node.js binary natively.

Now, an idea floated around is to add an extension API to the module, to allow the algorithms to be extended by options, which by extension, means one could publish a compression-brotli module to npm with this module as a dependent, rather than forking and maintaining a fork. Users who are OK with native module can use an extended version.

I think the biggest limiting factor to adopting this is that doing the compression within Node.js is just in the end bad for performance. At least with the algorithms built into Node.js directly (I cannot speak for how any native modules are implemented), the compression is happening as work items on the built-in thread pool within Node.js. The thread pool by default is only 4 threads, which can be a serious bottleneck, especially when you realize that all file I/O and even the default DNS operations all need to happen in that thread pool as well (sharing just 4 threads!). Couple that with most Node.js deployments being fronted with a LB like NGINX which can transparently add compression.