Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125626
Content-Type: text/plain;
	charset=utf-8
Precedence: bulk
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.10\))
Subject: Re: [PHP-DEV] Zephir, and other tangents
In-Reply-To: <CA+JpajnQj-Y7OhpUWqi0r7fKmvwCfpt35R6gv4zydK67DkTv4A@mail.gmail.com>
Date: Wed, 18 Sep 2024 15:33:24 -0400
Cc: Adam Zielinski <adam.zielinski@automattic.com>,
 PHP internals <internals@lists.php.net>,
 Dennis Snell <dennis.snell@automattic.com>
Content-Transfer-Encoding: quoted-printable
Message-ID: <E96AEF76-0823-4CE0-8E87-DDBAF35B8F59@newclarity.net>
References: <A247BB36-9FD1-4AAF-AAB8-82DBD9DE3550@newclarity.net>
 <CA697780-BC2D-4054-A9FD-523E08236732@rwec.co.uk>
 <8D420123-4ECF-48FD-A9C3-F80C60457A37@newclarity.net>
 <CA+Jpajkx0OraH7GQyB5gECtPOo2JP=RzuSwqfv4AZGY+a+ryPw@mail.gmail.com>
 <AACF228F-53D3-480F-9127-77FBC4AE6A84@newclarity.net>
 <CA+Jpajkuccd1XAur9pXp5u4yNGsHmH9B_8ugK+Q7rT9P4wvUYw@mail.gmail.com>
 <CAGnYymDigWop7+XOAv_HtsYtW4oPE=QuHtehafrgLSOz73VuDg@mail.gmail.com>
 <CA+JpajnQj-Y7OhpUWqi0r7fKmvwCfpt35R6gv4zydK67DkTv4A@mail.gmail.com>
To: Hammed Ajao <hamiegold@gmail.com>
From: mike@newclarity.net (Mike Schinkel)

> On Sep 18, 2024, at 3:09 PM, Hammed Ajao <hamiegold@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-si=
de-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-W=
ebAssembly-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.
=20
> 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=E2=80=94similar to =
AssemblyScript=E2=80=94or simply leaving it up to the library authors to =
choose lower-level languages (as is currently the case).
>=20
> 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.=20

Partial redundancy is not redundancy.=20

WASM's ability to run on a managed server =E2=80=93 assuming it were =
built-in to PHP core =E2=80=94 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=