> On Sep 19, 2024, at 12:00 PM, Rowan Tommins [IMSoP] <imsop....@rwec.co.uk> > wrote: > > On Wed, 18 Sep 2024, at 20:33, Mike Schinkel wrote: >> Yeah. That was the original goal. >> >> But to say WASM's domain is limited to browsers is not valid any longer: >> [...] > > While it's definitely interesting seeing what uses it's being put to beyond > the browser, the majority of those articles are talking about using WASM on > its own, in the kind of places where you might use a container, to host > things like microservices, serverless functions, etc.
Sigh. I did not include all potential examples. Leave it to you to limit your characterizations to only the ones I included. Here is another: https://github.com/wasmerio/wasmer-php > Embedding it into other languages is a different usage again. It's certainly > something that is being explored, e.g. by Extism, and that seems like a good > project for anyone interested here to participate in, e.g. to help design the > "glue" between PHP and WASM / Extism. Moot point as it cannot be run on a managed hosted server. https://github.com/extism/php-sdk >> WASM's ability to run on a managed server – assuming it were built-in >> to PHP core > > Just to reiterate, if by "built-in to PHP core", you mean "every copy of PHP > includes a functional WASM runtime", that's not going to happen. It would > mean bundling (or requiring every user to install) a huge third-party > dependency, with all of its dependencies and platform requirements, even if > they weren't interested in using it. So why do you claim that bundling a third-party dependency is a "never going to happen" scenario? By that logic PHP would have none of these functionalities: • cURL • GD • PDO • OpenSSL • MBString • Zlib • Zip • XSL • EXIF • BCMath And PHP would be much less useful without any one of them. > The only runtimes where WASM is ever going to be available "out of the box" > are those already built on a JavaScript engine (usually V8), like node.js, > Deno, Electron, etc. The WASM is then running inside the existing runtime, > not a whole new VM - like running Scala and Java code in the same JVM; or > Hack and PHP in (older versions of) HHVM. Seems you do not actually understand WASM runtimes. While WebAssembly is available "out of the box" in JavaScript-based runtimes like Node.js, Deno, and Electron, it is not limited to them. Standalone WebAssembly runtimes like Wasmtime and WAVM allow WebAssembly to be run as a general-purpose compute target, outside the scope of a JavaScript engine. > On Sep 19, 2024, at 4:41 PM, Hammed Ajao <hamieg...@gmail.com> wrote: > > 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? To be clear, shared hosting and managed hosting can be VERY different animals. I am advocating for enterprise-level managed hosting — like Pantheon — not shared hosting like GoDaddy. > On Sep 19, 2024, at 4:12 PM, Hammed Ajao <hamieg...@gmail.com> wrote: > On Wed, Sep 18, 2024, 1:33 p.m. Mike Schinkel <m...@newclarity.net> wrote: > But to say WASM's domain is limited to browsers is not valid any longer: > > I don't know where you got that since I never said anything along those lines. You did not say that explicitly, but you strongly implied it. Had you not meant to imply it then you'll argument would have made little sense because you would been implicitly admitting there are other uses for it. > But since you have all those guides and it's so practical, what's stopping > you? You'd do a better job of convincing me with a MVP than some random blog > posts. Here you go: https://github.com/wasmerio/wasmer-php BTW, as you being a C++ developer your argument is rather cynical because most PHP developers do not have the skills to write PHP extensions or work with FFI, and it is not a skill that can be acquired in a few weeks worth of free time. So you saying "Just do it" can be seen by a cynical person as you attempting to shut down discussion by presenting a blocking task that you can be pretty sure is too high a technical bar for most PHP developers. I do want to gain that skill, but I doubt that I will be able to any time in the near future, especially not with other work commitments. > - https://docs.docker.com/desktop/wasm/ > > You mean the feature that's been in beta since 2022? Yeah that's exactly what > I'm referring to. If docker and all their money and engineers haven't shipped > wasm in 2 years, how long do you think it'll take a bunch of volunteers? Shipping as a container runtime without the surrounding support of a host is a bit more complicated than implementing within a host. By your argument Node, Deno, and Wasmer would not have been able to ship WASM support yet. > You can't do shit on a managed server, that is not the bar at all. Who made you the arbiter of what the bar should be for the needs of other people? > What makes you so sure that wasm will be allowed on managed hosts? What's the > incentive for providers to allow it? The incentives would be market differentiation and customer demand. For security reasons it does not matter if customers demanded FFI or extensions written in C, there is simply too much risk. But if there were a sandboxed secure runtime shipped with PHP, especially one that could be memory-limited and CPU-throttled, then it would be easy for some managed hosts to decide to enable it. Not all would, but channeling your imagined role as arbiter, I would say that is not "the bar." > > Extensions, which are already implemented in lower-level languages like C > > or C++, would still need to be compiled to WebAssembly if the goal were > > full compatibility. When did I or anyone proposing WASM for PHP suggest that making compiling extensions into WebAssembly would necessarily be a blocking requirement? > This might lead us down the path of either creating a domain-specific > language (DSL) for PHP—similar to AssemblyScript—or simply leaving it up to > the library authors to choose lower-level languages (as is currently the > case). Or, simply allowing AssemblyScript as the initial way to use WASM in PHP core. > > In essence, WebAssembly is great for certain scenarios, but PHP has > > existing mechanisms that make the addition of a Wasm runtime potentially > > redundant for most use cases. Then for those cases where it is redundant, don't use it. > I hear you, you want to run low level code on managed servers. I would > approach the problem differently e.g. Creating some kind of directory for > `trusted` php extensions, the criteria for what qualifies as `trusted` would > be up for discussion. Or maybe we can bundle a small std lib of select > extensions with core. Those make a lot more sense to me than adding an entire > abstraction layer. Many hosts already whitelist php extensions. That does not help. The use-case being discussed by me and the others who commented in support of WASM is primarily bespoke code written for project-specific requirements. I am not saying WASM has to be the thing to meets that need, but AFAIK there is no other potential similar solution that could address it. You can dismiss that goals as being unimportant or "not making sense," but that does not mean there are not those who find meeting that need to make a lot of sense. Let me turn it around then and ask that — rather than being the gatekeeper against a solution— you instead propose a solution to address all the following requirements: Ability to run some form of module/add-in/extension/whatever-you-want-to-call-it in PHP that: 1. Ships with PHP code so those managed hosts who want to enable it can easily do so, 2. Allows for fully-bespoke project-specific things to be developed, 3. Is reasonably easy to program in a secure way (not C or C++), 4. Enables near native performance for things like looping and string manipulation and maths, and 5. And is secure, can limit memory use, and can throttle CPU hogging so hosts will not object to enabling it. Since you have already dismissed WASM as not the right approach, how would you alternately address those requirements? -Mike
