[throw_m239339]

That article doesn't explain what the WASM code does in Drupal.

[berkes]

I understood that Drupal/php is compiled to WASM and then run on a WASM runtime.

So no WASM inside Drupal, but Drupal run as, and in WASM.

[angelmm]

Exactly. The Drupal code is unmodified and runs on top of the PHP interpreter compiled to Wasm [0]. The Drupal PHP code is not compiled to Wasm.

- [0] https://github.com/vmware-labs/webassembly-language-runtimes

[berkes]

Is that possible, though? To compile PHP to WASM seems possible¹, but not sure if Drupal can be compiled: drupal does (did? back when I did Drupal it certainly did. I certainly did) some really funky metaprogramming and eval() stuff. Like keeping PHP in the database.

¹https://github.com/wapm-packages/php

[gzurl]

I think you missed this paragraph:

The Apache HTTP server and the Drupal packages remain unchanged. However, instead of loading the libphp.so extension module, it incorporates mod_wasm.so. In addition, instead of relying on the traditional PHP interpreter, it utilizes a PHP build in the WebAssembly binary format.

[SoftTalker]

So instead of trusting libphp.so, you have to trust mod_wasm.so that is running a php interpreter internally. Is this a win? Genuine question.

[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.