Thanks for your thoughtful response, Mike. I hope everyone had a nice weekend.
> However, my guess is that Automattic (spelled correctly) is not likely to do > that given how dismissive PHP Internals and by extension the PHP Foundation > has been regarding the needs of WordPress users for as long as you Arvids > have been doing PHP. > > > But who knows, maybe there could be a détente? Who on this list would be > more open than in the past to treat concerns of WordPress users as legitimate > rather than dismiss them because (I am paraphrasing) "how bad their code is?" > > At Automattic we’re used to working in the open. With WordPress itself (apart from Automattic) even more so. Dismissal is my bread and butter 😄 But we’re still working hard to make the web a better place and I’m happy to partner with anyone, even if we share disagreement. > Or the ones who want to target the users of the CMS or Framework that > recommend or require the extension. > > > If the extension were bundled then I expect it could become a recommended > extension for hosts to enable and WordPress could start shipping WASM > extensions for the use-cases Dennis Snell mentioned that can optionally run > if the WASM extension is enabled vs. if not it would just run the old slower > PHP code. > > > BTW, Dennis, could you see WordPress recommending a WASM extension if PHP > bundled one here? > https://make.wordpress.org/hosting/handbook/server-environment/#php-extensions > > > > Absolutely, though realistically we’re still talking about _years_ before it could be required. We’re not going to alienate a broad swatch of the internet just to get a new feature. But WordPress has become more assertive in pushing updates, both on users and on hosts. There is a component of the decision that depends on how many sites are still using old versions and there is a component that looks at things like security issues, whether a version is supported, and whether hosts offer the newer versions. WordPress today requires PHP 7.2.24, though that’s hidden in a paragraph of text after stating that the recommended minimum is 7.4. I believe that the update cycle has been contracting over time and the ecosystem is doing a much better job today at keeping updated than it was a decade ago. My guess is that we could see rapid adoption of some WASM extensions and add it to the recommended list. This is _my_ opinion though, and other maintainers may disagree. > >> How would we handle the JS-like stdlib of assembly script? Another >> abstraction layer? That seems easier to you than a DSL created specifically >> for this? >> >> >> > > > > > At this point I am realizing I might have completely misunderstood the original tangent into WASM. For one, I also find the idea of a DSL surprising for the needs being discussed. I’d like to understand better what this means, or what kind of extension would benefit from such a DSL, and what stage of the build this is being discussed (for example, a DSL for more easily writing PHP extensions in C, or a DSL like eBPF which PHP code can build as a string and submit for processing internally). > > >> With PHP like syntax? >> >> >> > > Why is "PHP like syntax" a blocking requirement? C does not have a PHP-like > syntax, or at least one that is not more similar to AssemblyScript than PHP. > Why then is C acceptable for extensions but AssemblyScript is not? > > > And even so, there is no reason a PHP-like syntax is required. PHP developers > work with JS or TS every day, and AssemblyScript is just a variant of > TypeScript. > > > > > > What does it mean to build a WASM runtime _for AssemblyScript_? When I think about it, I consider a real black-box implementation with basic means of transferring primitive data types across the barrier. In JS we have numbers and shared memory buffers. This leaves many things wanting, but also is “enough” and makes the security domain much smaller and easier to ensure. I’m not sure how to visualize what people are discussing when they talk about designing something for AssemblyScript. Would that exclude the ability to run C applications or Rust applications compiled to WebAssembly? > Once CMS & Frameworks are empowered to use WASM as part of their core > offering then they could start recommending WASM and managed web hosts that > want to cater to their users would start offering WASM enabled on their > platforms. > > > BTW, very few CMS or Frameworks make any extensions not referenced in > production.ini as requirements, and for very good reason because doing so > would be too risky. > > > > > We can flip the discussion, too. The idea of running code on a WASM runtime from PHP isn’t just about stuffing new complexity into PHP. The day we _require_ a WASM runtime is the day we can drop almost every other PHP extension from the required list. It’s great having `curl` and `exif` and `pcre` available, but the fact that they may not be makes every call out to them a liability - every call needs to a fallback implementation in user-land PHP or else we’re going to have to deal with site crashes. Even extensions like `mb_string` are incredibly useful, but only because we don’t have access to tools that better fit the needs we have as a CMS. There are some very surprising code snippets that exist (a) because `mb_string` isn’t guaranteed to be there and (b) because the interface is close enough to look right but different enough to be extremely awkward. One quick example comes up from just two nights ago: detecting URLs. We want to have a Unicode-aware `strspn()` function, so we have to use PCRE with the Unicode flag set. Now we have dependencies on extensions and no practical fallback, also the code in JavaScript cannot be the same because they use different regular expression syntax and people have to manually and correctly translate that. (Well, I have proposed some user-space PHP code to provide a streaming UTF-8 decoder, but it’s much slower than the C code inside PHP or the WASM binary would be). One new algorithm, compiled to WASM, could return the byte-offsets into a string where URLs are detected and then the PHP and JS could have a stable agreement and it wouldn’t depend on any other extensions than WASM. Having spent years dealing with text encoding issues I’d cheerly replace existing `mb_` code in WordPress with custom functionality as a WASM module. And again, I want to highlight that this is a win for hosts. Nobody needs to ask their host to install new extensions, no host has to evaluate the security or reliability of an extension. Nobody has to come begging for a rapid update to `openssl` because some vulnerability gave internet visitors root-level access on the host’s server. Nobody has to be disappointed because their host refuses to make `libvips` available to PHP code for the one site on their service that wants it. Hosts can start _removing_ extensions that have long been headaches but are so necessary in practice that they can’t get rid of them. —— This was supposed to be a very brief response. Sorry, and thanks for your patience reading through to the end. I’m responding because I feel like the conversation is relevant and good, but my tone is meant to be friendly with a realizing that none of this stuff is likely happening rapidly, and nobody is demanding this work. I want PHP to grow and mature, as I hope all here do, and I’m sharing where I can see WASM being the missing piece that we’ve wanted or needed for a long time to relieve pressure from the core language and escape from many of the legacy warts that make building reliable performant software in PHP so difficult. Warmly, Dennis Snell
