On Wed, Sep 18, 2024, 1:33 p.m. Mike Schinkel <m...@newclarity.net> wrote:
> > On Sep 18, 2024, at 3:09 PM, Hammed Ajao <hamieg...@gmail.com> wrote: > > Yes and no. The primary goal of WebAssembly is to support > high-performance applications on web pages. The premise is simple: > JavaScript is the only language natively supported by browsers, but > developers want to use various other languages (e.g., C, C++, Rust), > particularly for performance-critical tasks. WebAssembly allows code > written in these languages to be compiled to a universal format (Wasm) that > browsers can run efficiently. > > Yeah. That was the original goal. > That is the primary goal. > 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. All I did was try to explain to you why browsers need wasm and why it makes sense for them to invest in implementing 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. This is what we use for chrome/v8: https://github.com/WebAssembly/wasm-c-api/, have fun. - > https://www.webassembly.guide/webassembly-guide/webassembly/webassembly-in-the-server > - > https://blog.pixelfreestudio.com/how-to-implement-webassembly-in-server-side-applications/ > - https://medium.com/wasm/webassembly-on-the-server-side-c584f874b4a3 > - https://www.secondstate.io/articles/why-webassembly-server/ > - > https://www.techtarget.com/searchitoperations/news/252527414/Server-side-WebAssembly-prepares-for-takeoff-in-2023 > > And even: > > - 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? > > > However, in the case of PHP, many of the benefits that WebAssembly > brings to other languages are already available through PHP extensions or > FFI for non-performance-sensitive tasks. Integrating a Wasm runtime into > PHP would be a complex undertaking with significant risks, but it wouldn't > necessarily provide proportionate rewards, which is the main point I'm > trying to make. > > Many of the benefits, but NOT the most important one for a large number of > installations. > The benefit that neither FFI nor extensions can touch is the ability to be > run on a managed server. Without that, none of the other benefits of FFI > nor extensions even matter. Full stop. You can't do shit on a managed server, that is not the bar at all. What makes you so sure that wasm will be allowed on managed hosts? What's the incentive for providers to allow it? > > 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. 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). > > > > 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. > > Partial redundancy is not redundancy. > > WASM's ability to run on a managed server – assuming it were built-in to > PHP core — is the critical non-redundant benefit. If you cannot run those > "existing mechanisms" then they fact they are redundant does not matter one > iota. > 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. Cheers. Hammed.
