> To summarize, I think PHP would benefit from: > > 1. Adding WASM for simple low-level extensibility that could run on > shared hosts for things that are just not possible in PHP as described a > few paragraphs prior, and where we could enhance functionality over time, > > 2. Constantly improving PHP the language, which is what you are solely > advocating for over extensibility, Hi Mike,
I’m Adam, I'm building WordPress Playground [1] – it's WordPress running in the browser via a WebAssembly PHP build [2]. I'm excited to see this discussion and wanted to offer my perspective. WebAssembly support in PHP core would be a huge security and productivity improvement for the PHP and WordPress communities. > To summarize, I think PHP would benefit from: > > 1. Adding WASM for simple low-level extensibility that could run on > shared hosts for things that are just not possible in PHP as described a > few paragraphs prior, and where we could enhance functionality over time, Exactly this! With WASM, WordPress would get access to fast, safe, and battle-tested libraries. Today, we're recreating a lot of existing libraries just to be able to use them in PHP, e.g. parsers for HTML [3], XML [4], Zip [5], MySQL [6], or an HTTP client [7]. There are just no viable alternatives. Viable, as in working on all webhosts, having stellar compliance with each format's specification, supporting stream parsing, and having low footprint. For example, the curl PHP extensions is brilliant, but it's unavailable on many webhosts. With WebAssembly support, we could stop rewriting and start leaning on the popular C, Rust, etc. libraries instead. Who knows, maybe we could even polyfill the missing PHP extensions? > 2. Constantly improving PHP the language, which is what you are solely > advocating for over extensibility, Just to add to that – I think WASM support is important for PHP to stay relevant. There's an exponential advantage to building a library once and reusing it across the language boundaries. A lot of companies is invested in PHP and that won't change in a day. However, lacking access to the WASM ecosystem, I can easily imagine the ecosystem slowly gravitating towards JavaScript, Python, Go, Rust, and other WASM-enabled languages. Security-wise, WebAssembly is Sandboxed and would enable safe processing of untrusted files. Vulnerabilities like Zip slip [8] wouldn't affect a sandboxed filesystem. Perhaps we could even create a secure enclave for running composer packages and WordPress plugins without having to fully trust them. Another use-case is code reuse between JavaScript and PHP. I'm sceptical this could work with reasonable speed and resource consumption, but let's assume for a moment there is a ultra low overhead JavaScript runtime in WebAssembly. WordPress could have a consistent templating language. PHP backend would render the website markup using the same templates and libraries as the JavaScript frontend. Half the code would achieve the same task. Also, here's a few interesting "WASM in PHP" projects I found – maybe they would be helpful: - WebAssembly runtime built in PHP (!) https://github.com/jasperweyne/unwasm - WebAssembly runtime as a PHP language extension: https://github.com/veewee/ext-wasm - WebAssembly runtime as a PHP language extension: https://github.com/extism/php-sdk [1] https://github.com/WordPress/wordpress-playground/ [2] https://github.com/WordPress/wordpress-playground/tree/trunk/packages/php-wasm/compile [3] https://developer.wordpress.org/reference/classes/wp_html_processor/ [4] https://github.com/WordPress/wordpress-develop/pull/6713 [5] https://github.com/WordPress/blueprints-library/blob/87afea1f9a244062a14aeff3949aae054bf74b70/src/WordPress/Zip/ZipStreamReader.php [6] https://github.com/WordPress/sqlite-database-integration/pull/157 [7] https://github.com/WordPress/blueprints-library/blob/trunk/src/WordPress/AsyncHttp/Client.php [8] https://security.snyk.io/research/zip-slip-vulnerability -Adam
