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

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

But please don't forget to wrap it in at least some VM! /s

That's not even funny, as in real life people would run something like that actually in a VM.

So we have now: HW memory protection -> HW virtualization -> VM -> OS -> Docker -> WASM -> language runtime -> some code snippet.

Things become quite crazy these days, to be honest…

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.