[jeroenhd]

I don't see a breakdown of the costs of this layer of hardening. There's nothing on performance, memory usage, library and database support, and so on. Just a few modules that don't work optimally, noticeably the OpCode cache that speeds up PHP quite significantly.

Just stuffing something in a sandbox is easy. Set up a VM and don't add a network card and you've got a near perfect sandbox without any performance overhead. Maybe even do so for each request through Firecracker if you fear memory persistence. What matters is all the added complexity and the downsides of each solution.

Without any comparison, this attempted sales pitch for WASM is little more than a showcase, like when someone runs WINE in the browser.

[ridruejo]

You are completely correct. These are just the early steps to get it into people's radars. We follow the Unix approach of "Make it work, make it right, make it fast". We are on the "make it work" step and moving to "make it right", for which we will focus to run as many unmodified applications as possible. This requires better support for PHP features that still depend on WebAssembly-related features that are not fully baked yet (ie threading, WASI preview 2) as well as adding over the network database support (ie MySQL) since most apps don't use SQLite in production.

Once all that is in place, you can move into the "make it fast" part, but for many scenarios where security is an issue (high profile websites) even a significant performance penalty (that can be offset with beefier hardware or caching) may be desirable.