Brotli compress/decompress of php.wasm + wp.data

[krishenriksen]

Fixed devDependencies whitespace issue

[adamziel]

Thank you @krishenriksen!

I know it took a lot of work to prepare this PR. At the same time, we may not need to handle the encoding manually – it seems like Content-encoding: br is natively supported by all major browsers. What do you think?

[krishenriksen]

Thank you @krishenriksen!

I know it took a lot of work to prepare this PR. At the same time, we may not need to handle the encoding manually – it seems like Content-encoding: br is natively supported by all major browsers. What do you think?

That's true if you host the project with a native server handling node.js, and can support the mentioned br content encoding.

However I don't know if the server utilizes maximum compression quality of 11

[adamziel]

It looks like the default level is 6 in Nginx, 5 in Apache, and can be set to 11 in both.

Aside, I wonder what’s the difference in file size and the compression/decompression time between 5 and 11 specifically for the .wasm and .data files used in this project

[krishenriksen]

Let's say you want to run this project without any server, which is my plan. You need to be able to compress, decompress in the browser, along with a few other things.

[adamziel]

@krishenriksen sorry for the radio silence, I've been traveling.

Let's say you want to run this project without any server, which is my plan.

That sounds interesting, tell me more please! Do you mean you want to use it with the file:/// schema, or how specifically? I assumed you need at least a static files server so that the users can download the project files from somewhere.

Decompressing in the browser might be slower even if the file size is lower. With a protocol-level compression you can use WebAssembly.instantiateStreaming and start parsing the .wasm as the browser receives the bytes. With the JS-level compression, these three steps can't be parallelized and become sequential:

• Downloading the wasm file
• Decompressing the wasm file
• Parsing the wasm file

This is to say that JS-level compression could cost more time than it saves – it would make sense to run some numbers before deciding one way or another.

You need to be able to compress, decompress in the browser, along with a few other things.

I'm noodling on another use-case. Support for shipping extra files (customized WP builds or composer dependencies) without running the file_packager.py would make this project more accessible for developers. I'm not sure what format would work the best for that – zip perhaps? It's easy to use but I wonder whether it limits the benefits of the protocol-level compression. If yes then .tar or .tar.gz perhaps?

Also, I wonder if it would make sense to ship the decompressor itself as a slim WASM module 😆

[adamziel]

This one seems stale so I’m going to close it. Happy to reopen any time there’s a renewed interest!