Hi George! I'm deeply sorry about my previous answer. My email client did something extremely funky with it, I don't know why.
Thanks for your feedback. Thanks for your patience as it took a bit long to answer, I have been out of office. Your suggestion for compiling PHP code into WASM is an interesting, complementary approach that could be built independently of this one. While appealing, it will require significant efforts to design and implement, as you have described in your post. Technically, the approach we chose boils down to adding support for another architecture to which the existing code of the PHP interpreter can be compiled to (such as x86 or Arm) with additional limitations regarding filesystem access, threading, etc. as Wasm standards evolve. Even with all the challenges, this is an approach that is well-defined and easy to understand and it is the one that other major languages such as Python and Ruby have taken to add Wasm support. We are familiar with https://github.com/seanmorris/php-wasm and we used it in an early proof of concept for running WordPress in the browser (https://wasmlabs.dev/articles/wordpress-in-the-browser/). This project is different from ours in that it targets browsers, where instead of using WASI, it leverages Emscripten and a JS engine to implement functionality. Our project is intended to run PHP in the server side without the need of a Javascript engine. Server-side WASM+WASI gives us out-of-the box security as compared to running the PHP runtime directly. So, one can run PHP applications with more security guarantees than running PHP directly on top of a non-sandboxed environment, even in containerized environments. This approach allows for easier reuse due to WASM’s portability. WASM runtimes are written to support an increasing number of platforms and not just server-side ones but also edge devices. Instead of having to compile the PHP interpreter for multiple triplets one can reuse the same PHP interpreter built for the wasm32-wasi target on any device with a WASM runtime. This way existing PHP applications can be moved to the edge in an even easier way. Considering reusability, we think investing this effort with PHP is crucial because of the vast adoption of the language. As mentioned earlier, other scripting languages like Python and Ruby have already taken steps in this direction, so their interpreter can be built for the wasm32-wasi target. Your concerns about performance are valid. However, WASM runtimes are working hard to reach near-native speeds with JIT and AOT optimizations. Thus, WASM performance is only bound to improve in the future. There is also work to be done in our own patch to support opcache, for example. At the end of the day, it all boils down to tradeoffs. This port does not interfere with running PHP in its current form in native environments but allows new scenarios and use cases for those that need it. Please let us know if this answered some of the questions that you raised. We would also love to hear feedback about other potential use cases or still missing things on which we should focus from PHP developers point of view. Thank you, Rafael Fernandez López.
