On Tue, Sep 17, 2024 at 8:30 PM Dennis Snell <dennis.sn...@automattic.com> wrote:
> > 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. > I'm not convinced. That's what they said about nodejs(same algos and same language on FE and BE). Except it's not really that consistent because there are several discrepancies between the browser and node runtime. I'll believe it when I see it. > 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. > I can see the appeal of that though. > The other major area is similar, and we’ve seen this with the HTML and XML > parsing work recently undertaken in WordPress. > Yeah you could talk about html parsing before 8.4 but with 8.4 we get lexbor (thanks to niels) and that's as good as it gets. Php already has beautiful support for XML though so I'm not sure why you would implement a parser yourself. 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. > What exactly do you mean by jump into wasm? Like hand write it? Or you mean jump into a language that can be compiled to wasm? How about debugging at runtime? And if you mean better performance than PHP, while that is likely, it isn't guaranteed. PHP is pretty fast and will be faster for some routines that are optimized by the engine. Wasm will never be as fast as extensions though because with extensions, all you're doing is extending the engine. Same as any internal extension. With wasm you're interoperating with an entirely separate VM. Additionally, it’s a perk being able to write such algorithms in languages > that aid that development through more powerful type systems. > We can agree on that. But I use C++ for my extensions so there's also that. 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. > Imo this is where FFI should shine but I'll admit that the current implementation is lacking in both security and functionality. 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. > Shared hosting for php gets you the worst possible version of php. Can't recompile to enable any bundled extension, can't install any new extensions, so how exactly would you approach this? Wasm bundled with the engine by default? Or some kind of opt in mechanism that shared hosters won't even be able to use? > > 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 > I actually love wasm, I'm currently in the process of compiling my mini php runtime to wasm (basically a browser only version of 3v4l). I'm not against this for any personal reasons, I'm simply not sure it's the right approach. Cheers, Hammed
