An honest, non-snobbish assessment of why a 30-year-old scripting language still powers three-quarters of the web — and why the architectural reasons behind that persistence are more interesting than the memes.

1. The Honest Starting Point

PHP is not cool. It has never been cool. And at this point, it has clearly decided not to care — which, arguably, is the coolest thing about it.

Every few years, someone publishes a piece declaring PHP dead. Meanwhile, PHP quietly powers roughly 74.5% of all websites with a detectable server-side language, according to W3Techs data from early 2025. That number is not a rounding error. That is not legacy inertia alone. Something more deliberate is happening, and it deserves a genuine look rather than a dismissive shrug.

Furthermore, the language itself is in the middle of the most productive creative period in its 30-year history. PHP 8.4 shipped Property Hooks and Asymmetric Visibility in November 2024 — features that had been on the community’s wish list for over a decade. PHP 8.5, released on schedule in November 2025, delivered the pipe operator alongside a proper URI extension and several other developer experience improvements. And PHP 8.6, currently in planning, looks set to add partial function application. The language is moving forward with purpose, not coasting.

A Note on Honesty: This article is not going to tell you PHP is perfect. It has real weaknesses — a complicated historical API surface, inconsistent function naming, and genuine challenges in certain async workloads. Those criticisms are addressed directly in the limitations section. But dismissing the language without engaging with what it has actually become in 2026 is not a technical argument — it is a fashion statement.

2. A Decade of Quiet Reinvention

To understand where PHP is today, it helps to appreciate how dramatically it has changed since the version that earned so much of its reputation. PHP 5, which many developers still mentally associate with the language, was genuinely difficult. Scalar type hints were absent, anonymous classes did not exist, and the object model was looser than most professionals wanted.

Then PHP 7 arrived in 2015 and changed everything. Performance roughly doubled compared to PHP 5.6, and the language finally got scalar type declarations, return type declarations, and the null coalescing operator. It was a watershed moment, yet much of the developer community had already moved on emotionally and never looked back.

The PHP 8.x series, beginning in 2020, continued this modernisation at pace. Attributes (annotations), named arguments, match expressions, union types, enums, readonly properties, intersection types, and finally the JIT compiler all arrived in quick succession. By the time PHP 8.4 shipped in late 2024, the language looked considerably more like modern Kotlin or Swift than the PHP of 2010.

2015

PHP 7.0 — The Turning Point

Performance doubled. Scalar types, return types, null coalescing operator. The language got serious.

2020

PHP 8.0 — JIT, Attributes, Match

JIT compiler, named arguments, union types, match expressions, attributes (native annotations). A fundamental modernisation.

2021–2023

PHP 8.1 · 8.2 · 8.3 — Enums, Readonly, Fibers

Enums, readonly classes, first-class callable syntax, Fibers for concurrency. A language maturing rapidly, one release per year.

Nov 2024

PHP 8.4 — Property Hooks & Asymmetric Visibility

The two most-requested OOP features in years, shipped together. A decade-long discussion finally resolved.

Nov 2025

PHP 8.5 — Pipe Operator, Clone With, URI Extension

Left-to-right function chaining, immutable object updates, and a standards-compliant URL parser. Functional programming sensibilities, PHP style.

3. PHP 8.4: Property Hooks and Asymmetric Visibility

Of all the PHP 8.x releases so far, PHP 8.4 arguably represents the most significant shift in how developers actually write object-oriented PHP code. Two features, in particular, arrived together: Property Hooks and Asymmetric Visibility.

3.1 Property Hooks

Property hooks allow you to define custom logic that runs when a class property is read or written — directly on the property declaration itself. This eliminates an enormous amount of getter/setter boilerplate that PHP developers have been writing for twenty years. The official PHP 8.4 release notes describe it as providing support for computed properties that IDEs and static analysis tools can natively understand, without docblock workarounds that drift out of sync.

The practical impact is real. Developers have reported reducing model classes by 40–50% in line count while retaining the same type safety and validation logic. Furthermore, because hooks are understood natively by static analysis tools like PHPStan, there is no hidden magic — everything is inspectable.

PHP 8.4 — Property Hooks

class User {
    public string $email {
        // Runs on read — normalise to lowercase
        get => strtolower($this->email);

        // Runs on write — validate format
        set(string $value) {
            if (!filter_var($value, FILTER_VALIDATE_EMAIL)) {
                throw new InvalidArgumentException('Invalid email');
            }
            $this->email = $value;
        }
    }

    // Virtual property — no stored value, computed on read
    public string $domain {
        get => explode('@', $this->email)[1];
    }
}

3.2 Asymmetric Visibility

Asymmetric Visibility addresses a different but related problem: the desire to make a property publicly readable but privately or protectedly writable. Previously, this required a private property plus a public getter method — every time. Now, the intent can be expressed directly on the property declaration, making the API surface of a class immediately legible.

When the two features are combined — a hook with asymmetric visibility — you get a remarkably expressive tool for data objects: publicly readable, internally writable, with validation logic baked directly into the property itself. No getters, no setters, no magic methods.

PHP 8.4 — Asymmetric Visibility

class User {
    public string $email {
        // Runs on read — normalise to lowercase
        get => strtolower($this->email);

        // Runs on write — validate format
        set(string $value) {
            if (!filter_var($value, FILTER_VALIDATE_EMAIL)) {
                throw new InvalidArgumentException('Invalid email');
            }
            $this->email = $value;
        }
    }

    // Virtual property — no stored value, computed on read
    public string $domain {
        get => explode('@', $this->email)[1];
    }
}

25 Months in the Making: As documented by the PHP Foundation, the story behind these two features spans 25 months and five separate RFC attempts dating back to 2009. That the community got them across the finish line with a 42:2 vote for hooks and 24:7 for asymmetric visibility speaks to how much governance has matured around PHP’s development process.

4. PHP 8.5: The Pipe Operator Arrives

PHP 8.5, released on 20 November 2025, continued the trend of borrowing ergonomic ideas from functional programming languages and integrating them cleanly into PHP’s existing model. The headline feature was the pipe operator (|>).

In essence, the pipe operator allows you to pass the result of one expression as the input of the next, reading left to right rather than inside out. For PHP developers who have long relied on method chaining, it extends that pattern to standalone functions — a style that Laravel and Symfony users in particular had been approximating with collection classes for years.

PHP 8.5 — Pipe Operator

// Before: deeply nested, read inside-out
$slug = strtolower(
    str_replace(' ', '-',
        trim(' PHP 8.5 Released ')
    )
);

// After: left-to-right, exactly as you think about it
$slug = ' PHP 8.5 Released '
    |> trim(...)
    |> (fn(string $s) => str_replace(' ', '-', $s))
    |> strtolower(...);

Additionally, PHP 8.5 brought Clone With — a way to clone an object while updating specified properties in a single expression — and a new URI extension that finally gives PHP a standards-compliant URL parser following RFC 3986 and WHATWG standards. The latter is arguably overdue given that parse_url() has been showing its age for the better part of a decade.

Looking ahead, PHP 8.6 is expected to introduce partial function application, which will pair naturally with the pipe operator to enable genuine currying-style patterns. The foundation team has confirmed the RFC passed unanimously at 33:0.

5. The Numbers That Explain Everything

It is worth pausing on the market share data, because the numbers are genuinely extraordinary and they help explain why so many people keep learning PHP despite the cultural baggage.

Server-Side Language Market Share — Websites (2026)

To put those numbers in context: the nearest server-side competitor in raw web share is ASP.NET at roughly 7%, followed by Ruby at around 5%. PHP’s dominance in this specific niche — dynamic web content — is not contested. It is overwhelming.

It is also worth being honest about why that number looks the way it does. A large portion of WordPress installations are inactive, abandoned, or staging environments. As one careful analysis notes, the 43% figure represents W3Techs detections, not necessarily active, maintained sites. The real share of meaningfully active web properties is certainly lower. Nevertheless, the installed base of production PHP is enormous by any measure, and that installed base drives hiring, tooling, hosting infrastructure, and framework investment.

6. Performance: Honest, Not Hype

PHP’s performance story is one that deserves nuance rather than headline claims in either direction. The short version: for the workloads where PHP is overwhelmingly used — database-backed request-response web applications — modern PHP 8.x is fast enough that the language is rarely the bottleneck.

The longer version involves several components. OPcache, the bytecode caching layer, eliminates re-parsing on every request in production, and this alone makes a dramatic difference. The JIT compiler, introduced in PHP 8.0 and improved through 8.4 and 8.5, brings genuine gains for CPU-intensive operations. However, as the RFC authors themselves noted when shipping JIT, typical web apps like WordPress see modest improvements from JIT — the bottleneck is almost always the database or external I/O, not CPU-bound PHP execution.

Relative Request Throughput — PHP Version Comparison

Interestingly, PHP 8.3’s JIT was reported to outperform Node.js on certain CPU-intensive benchmark tasks, though Node.js maintains an advantage in I/O-heavy, high-concurrency workloads due to its event loop model. The practical lesson, as summarised neatly by multiple independent benchmarks, is that all three major web languages — PHP, Node.js, and Python — are fast enough for most applications when properly configured. The choice between them should be driven by ecosystem, team expertise, and workload characteristics — not by which has the most compelling benchmark headline.

FrankenPHP: A Runtime Worth Watching: One genuinely exciting development is FrankenPHP, which received official PHP Foundation backing in 2025. Built on top of Caddy, it operates in a worker mode that keeps PHP processes alive between requests — similar to how Node.js or Gunicorn work. Early benchmarks show ~15,000 requests/sec in worker mode compared to ~4,000 for traditional PHP-FPM. For teams that need more throughput without switching language stacks, FrankenPHP is worth a serious look.

6. The Architectural Reasons It Persists

Market share and language features are one part of the story, but neither fully explains why PHP persists so stubbornly. The deeper reasons are architectural and economic.

6.1 The Deployment Model Is Uniquely Forgiving

PHP’s shared-nothing, process-per-request architecture is often cited as a limitation. And for certain workloads, it is. However, it also means that deploying a PHP application to almost any shared hosting environment has been possible since the late 1990s. Upload files via FTP, done. This accessibility created the largest pool of web hosting infrastructure on the planet, and that infrastructure did not evaporate when Node.js became fashionable. Consequently, the economics of running PHP remain favourable for small to medium projects in a way that few alternatives match.

6.2 The Framework Ecosystem Is Genuinely Excellent

Laravel, in particular, has quietly become one of the most thoughtfully designed full-stack frameworks in any language. Its ecosystem — Eloquent ORM, Queue workers, Telescope for debugging, Octane for performance, Nova for admin panels, Livewire for reactive UIs, Jetstream for scaffolding, Forge and Vapor for deployment — rivals anything in the Node.js or Python ecosystem in terms of cohesion and developer experience. The JetBrains State of PHP 2024 survey found 61% of PHP developers use Laravel regularly.

6.3 Backward Compatibility Is Taken Seriously

PHP’s deprecation policy is conservative by design. Features are deprecated several versions before they are removed, and breaking changes are minimised. This means that organisations running large PHP codebases — and there are many — can upgrade gradually without full rewrites. The 89% PHP 8.x adoption rate by end of 2025, cited in the State of PHP survey, suggests the community does in fact upgrade, just steadily rather than abruptly.

7. The Legitimate Criticisms

A fair assessment requires acknowledging where the criticisms are well-founded, because some of them genuinely are.

The function naming inconsistency is real and not going away. strpos versus array_search, htmlspecialchars versus htmlentities, parameter order inconsistencies across the standard library — these are genuine rough edges. The language cannot easily fix them without breaking backward compatibility, so they persist. IDEs mitigate the pain, but the underlying inconsistency is a legitimate grievance.

The async story is still incomplete for applications that genuinely need it. Fibers, added in PHP 8.1, provide the building blocks, and tools like Swoole and RoadRunner offer event-loop models. However, compared to Node.js’s first-class async/await or Python’s asyncio maturity, PHP requires more infrastructure to achieve the same result. FrankenPHP is improving this picture, but the gap is real for high-concurrency workloads.

Finally, the talent quality distribution deserves an honest mention. Because PHP is so accessible and so widely deployed, the range of quality across PHP codebases in the wild is enormous. The best Laravel and Symfony code is excellent. However, because the barrier to entry is low, there is also a long tail of poorly written PHP in production that colours how many engineers perceive the language. This is not a language problem per se — JavaScript suffers from an identical dynamic — but it does contribute to the reputation issue.

8. The Verdict

The case against PHP in 2026 is mostly a case against its reputation, not its current capabilities. The language that genuinely deserved many of its criticisms — inconsistent, loosely typed, architecturally chaotic — has been replaced, version by version, by something considerably more considered.

Property Hooks and Asymmetric Visibility make the OOP model genuinely expressive. The pipe operator brings functional composition into the mainstream PHP workflow. The JIT compiler continues to mature. The framework ecosystem, led by Laravel, is world-class. The hosting infrastructure is universally available. And the installed base — three-quarters of the web’s server-side language share — ensures that PHP jobs, PHP libraries, and PHP hosting continue to be economically supported.

Therefore, the question is not really whether PHP should persist. It already has, and for structural reasons that will not dissolve because the developer discourse has moved on. The more interesting question is whether the developers who dismissed it five years ago have noticed what it has become. For many, the honest answer is probably no — and that is a gap worth closing.

9. What We Have Learned

PHP in 2026 is a language in active, deliberate evolution — not a relic being kept alive by inertia alone. Here is a concise summary of the ground covered:

• PHP 8.4 (November 2024) shipped Property Hooks and Asymmetric Visibility — ending 15 years of getter/setter boilerplate and making OOP code dramatically more expressive.
• PHP 8.5 (November 2025) delivered the pipe operator, Clone With, and a standards-compliant URI extension, bringing functional-style ergonomics to everyday PHP code.
• PHP 8.6 is expected to add partial function application (passed 33:0), complementing the pipe operator for more advanced functional composition.
• PHP powers ~74.5% of websites with known server-side languages, and WordPress alone accounts for ~43% of all websites — making the language’s persistence structural, not accidental.
• Modern PHP performance is competitive for typical web workloads. The bottleneck is almost always the database or I/O, not PHP itself. FrankenPHP’s worker mode is changing the throughput ceiling.
• Legitimate criticisms remain: function API inconsistency, an incomplete async story for very high-concurrency workloads, and a wide quality distribution in the wild.
• The architectural reasons PHP persists — universal hosting, conservative backward compatibility, excellent framework ecosystem — are structural and durable.