> On Sep 18, 2024, at 3:09 PM, Hammed Ajao <[email protected]> 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