On Mon, Jun 16, 2025, at 2:05 AM, wheakerd wrote: > Dear PHP Internals, > > I am submitting this proposal for discussion regarding a potential > future direction for PHP: moving toward a CLI-only development model > and introducing an optional Ahead-of-Time (AOT) compilation > infrastructure.
> All of this reflects a growing shift: **PHP is increasingly behaving > like a static backend language**, except it still runs on a dynamic > interpreter. > > This proposal attempts to provide native language support and compiler > infrastructure that aligns with these modern PHP usage patterns. This is true to an extent. Certainly there are ample places where the engine 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 worker mode Most code works, but it retains a persistent process. That makes all of the compiled graphs and such in-memory, which is exactly what 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 > but are **not required** for future application delivery. > - Built-in CLI runners or Web adapters (e.g., `php serve`, Swoole > adapters) provide development/testing environments. PHP-FPM and mod_php run 70%+ of the Internet. Deprecating them is not even remotely on the table until/unless other options like FrankenPHP become standard practice across the board, including in WordPress. Which means about 20 years, if we're optimistic and push hard on it. > ===== Compatibility Note ===== > This proposal is entirely opt-in and defines a **strict static subset > of PHP**. Dynamic runtime via Zend VM and JIT continues to be supported > and unchanged. This is an addition, not a replacement. That doesn't jive with what you had above about dropping PHP-FPM. > ===== Request for Feedback ===== > I’d appreciate feedback from internals and community members on: > > - 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 > userland tooling. > > ===== Note ===== > I would like to clarify that I am currently not in a position to > implement this proposal independently, as it would involve deep > modifications to the PHP runtime, compiler pipeline design, or > extension interfaces. > > This RFC is submitted with the intention of initiating structured > discussion and community exploration around this long-term direction. I > am willing to contribute research, coordination, and specification work > if there is interest from core contributors. > > I greatly appreciate any feedback, suggestions, or interest in > collaborating on prototyping or feasibility assessment. > > Sincerely, > [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 (ReactPHP, 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 the most widely used SAPI. Until then, this sort of "change the world" redesign is not feasible. --Larry Garfield
