> On Sep 17, 2024, at 2:03 PM, Rob Landers <rob@bottled.codes> wrote: > > > > > > On Tue, Sep 17, 2024, at 14:57, Adam Zielinski wrote: > >>> 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 >> >> >> >> >> >> >> > > Hey Adam, > > > > I actually went down something like this road for a bit when working at > Automattic. My repo even probably still exists in the graveyard repository… > but I had plugins running in C# and Java over a couple of weeks. This was > long before wasm was a thing, and while cool, nobody really could think of a > use for it. > > > > It seems like you have a use for it though, and I’m reasonably certain you > could get it working over ffi in a few weeks; yet you mention hosts not even > having the curl extension installed, so I doubt that even if wasm came to be, > it would be available on those hosts. > >
There are two major areas I have found that would benefit from having a WASM runtime in PHP: Obviously, being able to run the same algorithms on the frontend and backend is a huge win for consistency in applications. Particularly with text-related algorithms it’s really easy for inconsistencies to develop due to the features available in each languages standard library, as well as due to differences in how each language handles and processes string. The other major area is similar, and we’ve seen this with the HTML and XML parsing work recently undertaken in WordPress. There are plenty of cases where efficient and spec-compliant operations are valuable, but these kinds of things tend to cost significantly more in user-space PHP. Being able to jump into WASM, even with the overhead of exchanging that data and running another VM, would very likely result in a noticeable net improvement in runtime performance. Additionally, it’s a perk being able to write such algorithms in languages that aid that development through more powerful type systems. There’s additional value in a number of other separate tasks. Converting images or generating thumbnails is a good example where raw performance is less of a concern than being able to ensure that the image library is available and not exposing the host system to risk. I imagine plenty of “PHP lite-extensions” appearing in this space because it would give people the opportunity to experiment with features that are impractical in user-space PHP before fully committing the language itself to that interface or library. It would extend the reach of PHP’s usability because it would make possible for folks, who happen to be running on cheap shared hosts, to run more complicated processing tasks than are practical today. While big software shops and SaaS vendors do and can run their own custom PHP extensions, there’s not great way to share those generally to people without the same full control over their stack. > > > > However, plugins basically work via hooks/filters. So as long as you register > the right listeners and handle serialization properly, you can simply run a > separate process for the plugin, or call a socket for “remote” plugins. > > > > I don’t see anything stopping anyone from implementing that today. > > > — Rob > I’m excited to see this conversation. I’ve wanted to propose it a number of times myself. Warmly, Dennis Snell
