Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127693
Feedback-ID: i8414410d:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Mon, 16 Jun 2025 14:12:05 -0500
To: "php internals" <internals@lists.php.net>
Message-ID: <323c2a5d-d7a1-4b4e-831e-017b61e2b680@app.fastmail.com>
In-Reply-To: 
 <CAFJdCSsHhY6nAvjhCcohZxDtiQS=8B0=1RYH-ZyK+nW8xX6CrQ@mail.gmail.com>
References: 
 <CAFJdCSsHhY6nAvjhCcohZxDtiQS=8B0=1RYH-ZyK+nW8xX6CrQ@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] RFC Discussion - CLI-Only Development Mode and AOT
 Compilation Architecture
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: larry@garfieldtech.com ("Larry Garfield")

On Mon, Jun 16, 2025, at 2:05 AM, wheakerd wrote:
> Dear PHP Internals,
>
> I am submitting this proposal for discussion regarding a potential=20
> future direction for PHP: moving toward a CLI-only development model=20
> and introducing an optional Ahead-of-Time (AOT) compilation=20
> infrastructure.

> All of this reflects a growing shift: **PHP is increasingly behaving=20
> like a static backend language**, except it still runs on a dynamic=20
> interpreter.
>
> This proposal attempts to provide native language support and compiler=20
> infrastructure that aligns with these modern PHP usage patterns.

This is true to an extent.  Certainly there are ample places where the e=
ngine could be simplified or performance improved if we had a whole-app =
view at compile time.  But that is a vastly different language than what=
 we have today.

About 80% of the benefit you seek can be had today with FrankenPHP in wo=
rker mode  Most code works, but it retains a persistent process.  That m=
akes all of the compiled graphs and such in-memory, which is exactly wha=
t a persistent process compiled system would give you.  And ReactPHP has=
 been around since 5.4 or something, offering a persistent process with =
the same benefit (and the same tradeoffs).

> ### 3. CLI-Only Development Focus
> - CLI becomes the canonical platform for PHP execution and development.
> - PHP-FPM and SAPI models remain available for backward compatibility=20
> but are **not required** for future application delivery.
> - Built-in CLI runners or Web adapters (e.g., `php serve`, Swoole=20
> adapters) provide development/testing environments.

PHP-FPM and mod_php run 70%+ of the Internet.  Deprecating them is not e=
ven remotely on the table until/unless other options like FrankenPHP bec=
ome standard practice across the board, including in WordPress.  Which m=
eans about 20 years, if we're optimistic and push hard on it.

> =3D=3D=3D=3D=3D Compatibility Note =3D=3D=3D=3D=3D
> This proposal is entirely opt-in and defines a **strict static subset=20
> of PHP**. Dynamic runtime via Zend VM and JIT continues to be supporte=
d=20
> and unchanged. This is an addition, not a replacement.

That doesn't jive with what you had above about dropping PHP-FPM.

> =3D=3D=3D=3D=3D Request for Feedback =3D=3D=3D=3D=3D
> I=E2=80=99d appreciate feedback from internals and community members o=
n:
>
> - Whether such a compiler pipeline is desirable and feasible.
> - Acceptability of the required language subset restrictions.
> - Pathways to prototype this outside core, e.g., via PHP extensions or=20
> userland tooling.
>
> =3D=3D=3D=3D=3D Note =3D=3D=3D=3D=3D
> I would like to clarify that I am currently not in a position to=20
> implement this proposal independently, as it would involve deep=20
> modifications to the PHP runtime, compiler pipeline design, or=20
> extension interfaces.
>
> This RFC is submitted with the intention of initiating structured=20
> discussion and community exploration around this long-term direction. =
I=20
> am willing to contribute research, coordination, and specification wor=
k=20
> if there is interest from core contributors.
>
> I greatly appreciate any feedback, suggestions, or interest in=20
> collaborating on prototyping or feasibility assessment.
>
> Sincerely,=20
> [wheakerd]

As Tim said, I think you vastly under-estimate the amount of effort you =
describe, even ignoring the massive existing ecosystem.  You're talking =
many years of work.

Using FrankenPHP worker mode or one of the Fibers-based frameworks (Reac=
tPHP, AmPHP, Revolt, etc.) will give you 80% of what you're looking for =
or better, today.  Talking about anything even more drastic is severely =
premature until that model achieves critical mass, and ideally becomes t=
he most widely used SAPI.  Until then, this sort of "change the world" r=
edesign is not feasible.

--Larry Garfield