assambar

The biggest gain comes from mod_wasm using a Wasm runtime to run the PHP interpreter in a sandboxed environment. And mod_wasm can be used the same with Python or Ruby, or anything that builds for WebAssembly.

- No errors (even fatal) from the Wasm module will bring down Apache HTTPD. - mod_wasm's code base is small enough to inspect thoroughly and test thoroughly to ensure it is secure - Indeed you will now have to trust the embedded Wasm runtime (wasmtime as of today). As a naïve analogy, this is the equivalent of trusting a virtual CPU(Wasm)+OS(WASI), which gets tested in thousands of other scenarios than the ones used in mod_wasm and issues get fixed and corrected asap.

- enabled more PHP extensions

- options to bundle the standard libraries along with Python and Ruby

I totally agree with you on how ridiculous this is. But it's all about trade offs in the end. In the case of Docker+Wasm you get portability and delivery speed.

You build one image for the wasm32/wasi platform and now it can run on any architecture that has Docker, just like that. And also you don't carry the whole OS baggage of a typical container. Only the language runtime. So download times are faster.

---

Lastly, the Docker deployment is just the easiest way for a WASM application to reach people. They can try it out without the necessity to setup and support a WASI runtime.

Ready-to-use python.wasm, also in a Docker+Wasm container image.