> 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. But to say WASM's domain is limited to browsers is not valid any longer: - 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/ > 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. > 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. -Mike
