PHP is not dead: what PHPDay 2026 left us with

At the end of every PHPDay edition, a ritual repeats: someone, somewhere, is writing yet another obituary for the language. And every time we return home with the same conviction: PHP is not dead this time either. This isn’t a consolatory joke. It’s what was seen on stage at the 2026 edition: a release process governed with discipline, agentic frameworks in full competition, real-time pushed as far as QUIC, and a community that consciously decides when to break its own past.

The narrative of PHP’s decline compared to Python and Node.js has dragged on for years. It is convenient because it relies on popularity rankings, and fragile because it confuses fashion with maturity. The vitality of a language is not measured by how many new recruits choose it for their first project, but by the quality of the process through which it evolves and the solidity of the tools surrounding it.

PHPDay 2026¹ was exactly this: a snapshot of an adult ecosystem. Let’s go through the talks that tell this story best, starting with the most uncomfortable question of all: how does a living language decide to evolve?

A language that evolves is a language that decides how to break its past

The first proof of maturity is not a feature. It’s a process.

In “Shipping PHP 8.5”, Volker, release manager for PHP 8.5², did something rare for a technical talk: he spoke less about the language’s new features and more about how it is decided what goes into a release and how it is “shipped.” The new native extension for URI management compliant with RFC 3986³, for example, does not stem from an individual choice but from a public path of proposal, discussion, and voting. Understanding this mechanism matters more than memorizing a single function: it says that PHP is not “managed” by a vendor, but deliberated by a community.

That mechanism became palpable in the “Panel: the future of PHP”, where Volker, Gary, Gina, Derick, and Sara discussed proposals that are still open: generics with type erasure, scope functions, and pattern matching. One may or may not agree with every single RFC, but the panel’s message was unmistakable: PHP evolves thanks to its community, and the invitation to join the mailing list and contribute was not rhetoric; it was an operational request.

The closing keynote by Gina, “Progress lies within Backwards Compatibility breaks”, focused on the truth we often prefer to ignore: breaking backwards compatibility is the necessary and inevitable price of progress. Gina used analogies with other sectors—rail transport, electricity—which sometimes rebuild entire infrastructures to simplify integrations and reduce maintenance costs in the long run. Treating breaking changes as accidents means condemning oneself to technical debt; treating them as investments means designing to last.

Those who manage PHP in production know this dynamic well. When Drupal 10⁴ was released on December 14, 2022, adopting Symfony 6⁵ and raising the minimum requirement to PHP 8.1⁶, the entire ecosystem had to adapt. It is a real case of how language evolution propagates across major CMSs, a topic we explore further when talking about the new era of content management with Drupal CMS. And right here lies the difference between suffering a breaking change and governing it: tools like Rector for automatic refactoring, PHPStan, and Psalm for static analysis allow for identifying deprecated code before migration, transforming a traumatic jump into a planned path.

A language that redesigns itself does not do so in a vacuum. It does so to stay on the hottest fronts of contemporary software.

PHP on the new frontiers: agentic AI and real-time communication

The PHP ecosystem is moving rapidly on the ground of agentic frameworks. An agentic framework, for those who don’t work with AI daily, is the infrastructure that allows a Large Language Model not just to respond, but to perform actions: invoke tools, consult sources, and orchestrate multiple steps toward a goal.

In the talk “The PHP AI Battleground: Choosing Your Agentic Framework”, our own Luca Lusso, lead developer at SparkFabrik, compared three promising PHP frameworks for agentic workflows: Laravel AI, Symfony AI, and Neuron AI. Each has pros and cons, and none is the universal answer. Laravel AI integrates naturally with those already living in the Laravel ecosystem; Symfony AI brings Symfony’s architectural rigor to the agent domain; Neuron AI was born leaner and more focused. The choice depends on the stack already in use and the workflow requirements. (We explore the Neuron AI framework further in our dedicated webinar “Building AI agents in PHP with Neuron AI”)

Some read this plurality as fragmentation. We read it the opposite way: three competing frameworks are the sign of a buzzing ecosystem that is choosing its own direction instead of being subjected to it. The critical point comes in the next phase: bringing an agent into production means governing a probabilistic system, and this requires dedicated observability practices, such as those we describe when talking about AgentOps, from monitoring token consumption to detecting hallucinations.

The same vitality was seen in real-time. In “PHP’s Real-time Toolkit: All the Ways to Notify Clients”, Grzegorz reviewed all the ways to push data from server to client: from old polling to modern patterns like WebSocket and Server-Sent Events (SSE), pointing to WebTransport based on QUIC⁷ over HTTP/3 as the future. In his presentation, he cited Mercure, presented as a solution based on the Server-Sent Events mechanism, and two more structured alternatives:

• Centrifugo: a platform that supports many protocols, scales well, and handles automatic fallbacks, at the cost of having to run a separate server.

• Nchan: an Nginx module conceptually similar to Centrifugo, but significantly more scalable.

Here too, variety is not dispersion. It is an ecosystem offering the right tool for every scale and infrastructure constraint.

Innovation without solidity remains fragile. The true maturity of PHP in 2026 is seen in the less flashy engineering details.

Maturity is in the details: data, serialization, and resilience

What makes a language suitable for production are not the surface features. It is the ability to handle data at volume, performance, and errors with discipline. PHPDay 2026 dedicated some of the densest talks to these themes—the ones that never make the headlines.

It starts with raw data. In “Data Processing in PHP”, Norbert showed how to extract and process large volumes of data efficiently and economically, starting from native PHP functions for handling a simple CSV file up to complete ETL processes built with flow-php, the tool he developed. The message: PHP handles serious data loads if you know how to structure the flow.

Then there is the speed problem. Michelle, in “Advanced Serializing in PHP: Speed it up!”, compared different serialization techniques starting from a counterintuitive fact: the Symfony Serializer is the most powerful but also the slowest because it uses reflection to access object state at runtime. The solution is to move complexity to code time, generating fast PHP code, previously with liip/serializer and today with its successor rebuy-oss/serializer. Michelle’s team went further, building a PHP-to-Go converter to execute the serialization phase in Go and squeeze out even more speed. It is the kind of engineering that is done only when a language is already in production on systems that matter.

Finally, resilience. In “Mastering Failures: Building Resilient PHP/Symfony Apps with Domain-Driven Exceptions”, Stephane taught the correct patterns for domain exceptions in Domain-Driven Design architectures: don’t throw generic exceptions, don’t parse error messages to understand what happened, define a specific exception for every real domain problem. His sharpest advice:

Don’t throw a NotFoundHttpException inside a domain, because the same code might also run in a CLI application.

It is a detail that separates a toy project from an enterprise system, the same decoupling rigor we find in the choices between monolith and microservices. These are the themes on which it is measured whether a community is adult. And PHP, here, is.

But isn’t PHP in decline compared to Python and Node? The factor that rankings ignore

Let’s face the strongest objection without running away. It’s true: public perception sees PHP in decline. New developers gravitate toward JavaScript and Python, AI and data science have made Python the default stack for entire categories of projects, and popularity rankings tell a downward story. Ignoring this would be dishonest.

Yet rankings measure fashion, not maturity. The numbers tell another story: PHP remains the server-side language of about 77% of websites with a detectable backend, and WordPress⁸ alone powers over 43% of the web. Adding Magento in e-commerce, Symfony and Laravel in enterprise, and Drupal in complex portals, the presumed end takes on rather lively contours.

The real point isn’t even these numbers. It’s the fundamentals.

In “Packets, Protocols and PHP: Networking Fundamentals for Developers”, Jessica led a tour of network layers, from Application to Physical in the OSI model, with the truth every sysadmin knows: “it’s always DNS (or BGP, or more often, both).” Networking fundamentals don’t go out of style and are independent of the language. Those who master them are better engineers, whatever stack they choose.

The solidity of an ecosystem can be read in its tooling. Derick, creator of Xdebug, in “Better Debugging With Xdebug” showed live the new features of Xdebug 3.5⁹: Native Path Mapping, out of band signalling, automatic line discovery, and more, as detailed in the official announcement. A debugging tool so well-maintained is proof of a community that invests in quality, not just features. It is the same commitment that as a Drupal Certified Partner Gold we bring to the maintenance of WebProfiler, the debug module for Drupal with over 1,000 active installations.

Judgment makes the difference. Gary, in “It Depends”, conducted an interactive session on the critical decisions every developer faces every day: monolith or microservices, hand-written or AI-generated code, opinionated or non-opinionated frameworks. The conclusion, honest and disarming, is the title itself: in the end, it depends. Maturity is not a dogma; it is contextual judgment.

Finally, the people. Carolina, a psychologist, held “Communication for devs: explaining complex ideas simply”, an interactive keynote in which we tried to improve our ability to explain: tell a story to the person sitting next to you, use an analogy, frame ideas from the listener’s perspective. The most important secret, she said, is to breathe.

Rankings measure popularity. An adult language is measured by its fundamentals, its tooling, and its people. And it is exactly on these axes that PHP, in 2026, is rock solid.

What remains of PHPDay 2026

“PHP is not dead” is not a defensive reassurance. It is the observation of a fact: a language capable of consciously breaking its own past to progress, as Gina argued, of competing on agentic frameworks and real-time, and at the same time of cultivating its fundamentals with discipline, is a deeply living language.

The real risk is not the end of PHP. It is that the community stops participating. The invitation that emerged from the panel—to join the mailing list, discuss RFCs, contribute—was not a ceremonial detail: it is the very engine that keeps the language alive.

From our experience with enterprise PHP codebases in production, this reading is the same one we see confirmed every day in the field. The right question, coming out of PHPDay 2026, is not “Is PHP dead?”. It is: do we have the technical and human maturity to use it as it deserves?

Notes and sources