Stop polishing the turd: a new "compromised" async model won't save PHP

[propress]

The Standard Library: A 20-Year-Old Mess

The PHP standard library suffers from a maddening issue: chaotic function parameter ordering. strpos($haystack, $needle) puts the string first, while str_replace($needle, $replace, $haystack) puts the pattern first. This schizophrenic API design has persisted for over two decades. Developers are forced to either memorize these inconsistencies by rote or constantly check the documentation.

This is the place that truly needs "standardization." Yet, the core team turns a blind eye. There is no unified replacement API, no deprecation plan—nothing. What are they busy with instead? Adding syntax sugar.

Over-Specification: Forcing Static Typing on a Scripting Language

Since PHP 8, there has been a frantic introduction of type system features. We now have verbose, suffocating property declarations like final public readonly ?string $property, and function parameters that look like algebra equations: A&B|C (intersection and union types).

What was PHP's core advantage? Rapid development, low barrier to entry, "write and run." Now? It is morphing into a discount version of Java. Piling static type features onto a dynamic language foundation is essentially over-engineering on a shaky architecture. Aside from increasing cognitive load, it offers little help to actual productivity. The standard library APIs—which actually need unifying—are ignored, while massive resources are poured into these flashy syntax features. The priorities are completely backwards.

JIT: A Classic Strategic Miscalculation

Web applications are I/O bound. The vast majority of a request's time is spent waiting for database responses, HTTP calls, or file reads. I/O waiting usually accounts for over 90% of the request duration.

So, what does the JIT (Just-In-Time) compiler—which the official team spent years developing—actually do? It optimizes computational performance. Who uses PHP to calculate the Fibonacci sequence? JIT might make fibonacci() several times faster, but in real-world Web scenarios, it does almost nothing for performance bottlenecks. This is a mismatch of resources and a clear strategic misjudgment.

Fiber: A Half-Baked Solution

Fibers, introduced in PHP 8.1, were advertised as coroutine support. In reality, Fiber is just a stack-switching mechanism. The official release provided no accompanying Event Loop, and the standard library's I/O functions remain entirely blocking.

It is a half-baked product. Developers cannot use raw Fibers effectively; they must rely on third-party libraries to complete the async stack. Because it is difficult to use and the ecosystem is fragmented, almost no one uses it. Without usage, there is no feedback, and iteration stagnates.

The result? Handling concurrency with Gearman and multi-process architectures—solutions from ten years ago—remains the mainstream best practice in native PHP today. The evolution from process to thread to coroutine has been forced into a "Resume-Driven Development" product, released just for the sake of releasing a version.

Community Efforts: Patching a Flawed Foundation

It’s not that the community hasn't tried. The pthreads and parallel extensions attempted to introduce multi-threading. ReactPHP proved the feasibility of async non-blocking I/O a decade ago. Swoole single-handedly dragged PHP into the coroutine era and is used at scale in production.

These projects proved that high-concurrency PHP is possible. And then?

These battle-tested solutions are either treated as outliers by the core team or left to sink or swim as mere "extensions," never truly absorbed into the language kernel. The official team chooses to ignore these paved roads, turning back to design the next complex piece of syntax sugar.

The root problem is this: The Zend Engine is not thread-safe by default, and the standard library is designed for blocking I/O. On this flawed underlying architecture, any extension solution is essentially patching a crumbling foundation. pthreads is no longer maintained; Swoole requires replacing the entire runtime; ReactPHP requires a completely different programming paradigm. Each has its pitfalls, and none can become the standard concurrency model for PHP.

The Real MVP: Back to Basics (Process -> Thread -> Coroutine)

We are trying to defy gravity. The natural evolution of concurrency is Process → Thread → Coroutine.

Process: We have this (PHP-FPM), but it's heavy.
Thread: We skipped this. Because the Zend Engine is not thread-safe (ZTS is optional and rarely used in production), we lack the foundation for shared-memory concurrency.
Coroutine: Now we are trying to force this onto a single-threaded, blocking architecture.
Without a thread-safe runtime or a built-in, unified Event Loop, any "Coroutine" solution is just syntactic sugar over a blocking implementation. It is not a true MVP (Minimum Viable Product).

A true MVP isn't "releasing a feature that technically compiles." A true MVP requires solving the root cause:

Make the Runtime Thread-Safe by default.
Provide a Standard Non-Blocking I/O Library (Event Loop).
Only then build Coroutines on top of that solid foundation.
Stop trying to build the third floor of a house that has no second floor. If we don't have the resolve to fix the foundation (Thread Safety & Non-blocking I/O), any "Async" solution we rush out now will just be more technical debt for the future.

The Reality: Continuing to Build on Sand

The current iteration model remains: don't refactor the core architecture, but keep adding new features. JIT is useless for the Web; Fibers are half-baked; syntax complexity continues to rise. And what is the community discussing? How to design the next version of the async model on top of this technical debt.

The consequences of this roadmap are already visible. Modern cloud-native environments like Lambda, Serverless, and WASM demand high concurrency and low cold-start times. PHP is non-competitive in these dimensions. The official team ignores the rotting foundation while planning to add another layer of flashy, impractical decoration on top.

PHP's former strength was simplicity and efficiency. It is now losing that original soul.

[macropay-solutions]

it does almost nothing for performance bottlenecks

Maybe it helps load symfony and laravel overhead faster.

[propress]

The PHP core team's priorities seem to favor the needs of the framework ecosystem.Framework developers have significant influence over the language's evolution, while regular application developers are largely passive recipients of these changes.

[macropay-solutions]

Sadly.

[EdmondDantes]

Programming is a process of creating value from existing value.
You take a ready-made framework, write code, and add value to value.
At the same time, your code interacts with other code.

In an ideal universe where people live for 100000 years, where projects can be developed for 1000 years, where there is no progress and no changing requirements, it would be possible to build applications with perfect code that almost never breaks and has beautiful APIs.
Ideally, all code would be written by a single person with unlimited memory and a huge brain.

In the non-ideal universe, development time is limited, requirements change, and code is written by different people, which is simply “terrible”.
Therefore, the code you interact with will always have flaws, to a greater or lesser extent.
The presence of flaws reflects the cost of development.

If you are programming in PHP, it means you chose one of the most efficient languages in the world in terms of the time to result ratio.
And this does not come for free.
Something must be placed on the altar of programming in exchange, the law of equivalent exchange.
The imperfection of PHP’s API is the price for its efficiency.

This is exactly why the language is successful.
This is not philosophy or allegory, it is literally cause and effect.

Because the Zend Engine is not thread-safe

(Looks surprised)

The concurrent execution model is the most efficient for Web server scenarios.
For a language that primarily serves such scenarios, it is more than sufficient at the current stage of development.

Unless, of course, you have the resources to create something entirely new.