PHP in 2026: The Language That Powers 72% of the Web Is More Interesting Than You Think

Every few years, someone publishes a confident piece declaring that PHP is dying. The language is too old, too inconsistent, too associated with the messy web of the early 2000s to survive the transition to modern development. The post gets shared enthusiastically by people who have already moved to other languages and need their choice validated.

Meanwhile, PHP quietly continues to run roughly 72% of all websites with detectable server-side languages. It shipped PHP 8.5.8 three days ago, on July 2, 2026. FrankenPHP, a new runtime built on top of PHP, is now delivering 15,000 requests per second in worker mode against the 4,000 that traditional PHP-FPM achieves - nearly four times faster, from the same language, on the same hardware. Laravel has evolved from a framework into something closer to a full-stack platform with its own cloud deployment product. PHP 8.6 is in active development for a late 2026 release.

The "PHP is dead" framing has always been wrong. But what is genuinely interesting about PHP in 2026 is not that it survived - it is that it has quietly become a more capable, more performance-competitive, and more productively satisfying language to work in than the version that earned the reputation most of its critics are still judging it by.

That story deserves to be told honestly, including the parts that are less flattering.

The Version Situation: Mostly Good, With a Persistent Problem

PHP 8.5.8 is the latest stable release as of this week, on the 8.5 branch that became generally available in November 2025. PHP 8.4 and 8.3 are both still in active support. PHP 8.2 is in security-only support. PHP 8.1 reached end of life in December 2024. PHP 7.x and anything older is completely unsupported - no security patches, no bug fixes, no official assistance of any kind from the PHP development team.

The good news from the JetBrains Developer Survey: 89% of PHP developers are now running PHP 8.x in some form. That is a meaningful improvement from where adoption stood two years ago and reflects genuine momentum behind the 8.x series.

The less good news from Zend's 2026 PHP Landscape Report: 40% of PHP teams are still running end-of-life versions in at least some of their infrastructure. That figure - four in ten - is striking for a language whose community has been pushing version upgrades aggressively for years, and it carries real consequences. An application running PHP 8.1 or earlier in production today has zero official security coverage. The vulnerability is not theoretical: a critical remote code execution flaw in Livewire (CVE-2025-54068, CVSS 9.8) was identified with over 130,000 public instances exposed - the exact kind of ecosystem-wide security event that running outdated software makes significantly harder to manage and patch.

The reasons teams stay on older versions are familiar and legitimate: upgrade friction, dependency constraints, legacy codebases with no test coverage, hosting environments that lag behind the stable release, and the simple inertia of applications that work until they don't. None of these reasons are irrational. All of them become more expensive over time.

The practical advice for anyone running PHP 8.1 or earlier: the migration path to 8.3 is well-documented, backwards compatibility within the 8.x series has been carefully maintained, and the security exposure of staying put is now concrete rather than hypothetical.

PHP 8.5: The Feature That Changes How You Write Code

PHP 8.5's most significant addition is the pipe operator, and calling it important is not hyperbole. It has been described by multiple PHP core contributors as one of the highest "bang for the buck" language improvements in recent PHP history - a claim that becomes clear the moment you see what it replaces.

The pipe operator, written as |>, passes the value on its left to the callable on its right. Before it existed, chaining multiple transformations on a string required either deeply nested function calls (read inside-out, which is cognitively backwards) or a series of intermediate variable assignments that exist purely to feed the next step. After:

// Before: nested or intermediate variables
$result = array_filter(
    array_map('strtolower', explode(',', $input)),
    'trim'
);

// After: pipe operator
$result = $input
    |> explode(',', ...)
    |> array_map(strtolower(...), ...)
    |> array_filter(...);

For anyone who has worked with pipeline-style code in Elixir, F#, or modern JavaScript, this is immediately familiar. For PHP developers who have not, the impact on readability in data-transformation-heavy code is significant enough that it genuinely changes how you think about structuring logic.

The clone with syntax is the other 8.5 addition worth immediate attention, particularly for developers working with immutable value objects. Previously, cloning an object while changing one or two properties required either breaking immutability or writing explicit withPropertyName() methods for every property. The new syntax handles this cleanly:

// Before: boilerplate wither methods or mutation after clone
$updated = clone $order;
$updated->status = 'shipped';

// After: clone with expression
$updated = clone($order, ['status' => 'shipped']);

Other 8.5 additions worth knowing: the new Uri extension provides standards-compliant URL parsing using both RFC 3986 and the WHATWG URL standard, finally replacing the unreliable parse_url() function that has been a source of subtle bugs for years. The array_first() and array_last() built-in functions arrive after years of developers writing their own equivalents. The #[\NoDiscard] attribute marks return values that should not be silently ignored, with the runtime emitting a warning when they are — addressing a class of bugs that was previously impossible to detect without static analysis.

PHP 8.6: What Is Coming Later This Year

PHP 8.6 is in active development targeting a late 2026 release, and the most significant confirmed addition is Partial Function Application - a feature that pairs directly with the pipe operator to make functional-style PHP considerably more expressive.

Partial Function Application lets you create a new callable from an existing function by pre-filling some of its arguments and leaving others as placeholders. The placeholder syntax uses ? for individual arguments:

// Partially apply array_map with strtolower already bound
$toLowerCase = array_map(strtolower(...), ?);

// Compose cleanly with the pipe operator
$result = $input |> explode(',', ...) |> $toLowerCase |> array_filter(...);

Operations which previously required verbose arrow functions inline - particularly when working with array_map, array_filter, and similar higher-order functions - can be written concisely as partially applied functions with configuration already bound. The PHP Foundation has also left open the possibility that the late 2026 release could be versioned as PHP 9.0 rather than 8.6, depending on the scope of changes accepted through the RFC process - potentially including native async/await capabilities the internals community has been discussing for some time.

FrankenPHP: The Performance Story Nobody Outside the PHP Community Has Heard

Here is the part of the PHP in 2026 story that deserves considerably more attention than it has received outside PHP-specific coverage.

FrankenPHP is a PHP runtime built on top of Caddy - the Go-based web server - using Go's concurrency model to handle PHP processes differently from traditional PHP-FPM. PHP-FPM (FastCGI Process Manager) handles each request by initialising a PHP environment, executing the script, and tearing down. FrankenPHP's worker mode works differently: PHP processes boot once, stay resident in memory, and handle multiple requests without the startup overhead of reinitialising the environment for each one.

The benchmark difference this produces is not incremental. The State of PHP 2026 report documents FrankenPHP delivering approximately 15,000 requests per second in worker mode against PHP-FPM's approximately 4,000 - a 3.75x improvement in throughput from the same application code, same hardware, same PHP version. This figure comes from the PHP Foundation's own benchmarking, which gave FrankenPHP official PHP Foundation support in 2026.

The caveats worth stating clearly: not every application benefits equally. Applications with shared mutable state that assumes per-request isolation need to be carefully audited before moving to worker mode, because the persistent process model changes the lifecycle assumptions that PHP developers have been writing against for years. Measure in your own environment before committing to migration, because the gains depend heavily on workload characteristics.

Laravel Octane - which has supported FrankenPHP as a runtime option since its early adoption — handles the lifecycle management that makes worker mode practical for most Laravel applications. The combination of Octane with FrankenPHP is increasingly the recommended architecture for high-throughput Laravel deployments.

Laravel's Vertical Integration: From Framework to Platform

The most strategically significant development in the PHP ecosystem over the past twelve months is not a language feature. It is what Laravel has done to its own product surface area.

Laravel 12 shipped in early 2026 with zero breaking changes, continuing the series' commitment to upgrade-friendliness. But the more significant story is what surrounds the framework. Laravel took over stewardship of Inertia.js - the library that bridges Laravel backends to React and Vue frontends without requiring a separate API - completing a deliberate vertical integration strategy. The Laravel ecosystem in 2026 now covers: the framework itself, Laravel Cloud for serverless deployment, Forge 2.0 for VPS server management, Nightwatch for production monitoring, Pest for testing (now at 17% PHP developer adoption, up four percentage points year-over-year), and Livewire and Inertia for full-stack development without leaving the PHP ecosystem. The positioning is explicit: Laravel is competing with Vercel and Heroku as a deployment platform, not just with Symfony and CodeIgniter as a framework.

Laravel's framework adoption sits at 64% among PHP developers per the JetBrains survey. Symfony, the other major serious framework, sits at 23% and has taken a different strategic path: the simultaneous release of Symfony 7.4 LTS and 8.0 with identical feature sets but diverging support timelines - 7.4 with security support until 2029, 8.0 beginning a new compatibility series - is an explicit commitment to enterprise stability that positions Symfony for the large organisations with multi-year upgrade cycles that represent a significant and underserved portion of PHP's production footprint.

The Talent Pipeline Problem Nobody Is Talking About Loudly Enough

The less comfortable part of the PHP in 2026 story is this finding from Zend's Landscape Report: experienced PHP developers are becoming harder to replace, and fewer new developers are entering the ecosystem.

The pattern is not unique to PHP - many mature, stable languages experience this as the next generation of developers gravitates toward newer ecosystems with more visible hype. But it is worth naming clearly because it has practical consequences that the "PHP powers 72% of the web" headline obscures. The TIOBE ranking decline —- from PHP exiting the top 10 in April 2024, to 13th in January 2025, to 15th in January 2026 - is one signal of this. The specific mechanism TIOBE measures (search query frequency, tutorial searches, job posting language, and similar proxies for developer attention) is telling you that PHP attracts less active new learning interest than it once did, even as it maintains its production footprint.

That gap between deployment share and learning interest is the specific dynamic that produces a talent pipeline constraint over a multi-year horizon. For teams hiring PHP developers in 2026, the labour market reality is tighter than the 72% deployment share would suggest. For developers considering PHP as a language to invest in learning, the career market is strong specifically because the supply of experienced PHP developers is constrained relative to continued demand. For organisations running legacy PHP applications, succession planning for the developers who built and maintain those systems deserves explicit attention that it often does not receive.

Where PHP Actually Stands - Without the Marketing or the Dismissal

The honest summary of PHP in July 2026 is more interesting than either the promotional version or the dismissive version suggests.

It is a language running on nearly three-quarters of the web's server-side infrastructure, maintained by an active Foundation with a reliable annual release cadence, shipping real and useful language improvements without breaking existing code, with a dominant framework that has expanded into a full-stack platform, and a new runtime that delivers performance benchmarks that would have seemed impossible for PHP five years ago.

It is also a language where 40% of teams are running EOL versions, where a critical ecosystem vulnerability this year exposed how much production infrastructure runs without adequate security maintenance, where the talent pipeline is tightening as new developer attention flows toward newer languages, and where the TIOBE ranking decline reflects a real shift in where learner attention and new project starts are concentrating.

Both of those paragraphs are accurate simultaneously. PHP is not dying and it is not without real challenges. The developers who will get the most value from it in 2026 are the ones who engage with both paragraphs honestly - upgrading to 8.5, evaluating FrankenPHP for high-throughput workloads, building the succession and hiring plans that a tightening talent market requires, and treating the language's genuine improvements with the same seriousness they bring to any other production infrastructure decision.

The "PHP is dead" takes have been wrong for twenty years. The "PHP is fine and nothing needs attention" takes are also wrong, in a quieter and more consequential way. The interesting position, as it often is, sits precisely between them.