Skip to content
Muhammet Şafak
tr
Languages 3 min read

Building Applications with PHP in 2026: State of the Ecosystem

The real state of PHP in 2026: language maturity, ecosystem health, and why the 'it's dead' narrative is still wrong.

Cover — a violet glass block set into a brushed metal base, reading PHP with VERSION 8.x and 2026 beneath it

I think I first heard “PHP is dead” sometime around 2012 or 2013. I’ve heard it every year since — sometimes riding alongside the rise of Node.js, sometimes buried in the data science wave around Python, sometimes as background noise beneath the latest “modern web” discourse. More than a decade has passed. PHP is still here, still being written, and still shipping products.

I’m not writing this as a defense. Spending energy proving that a language “isn’t dead” is not a productive use of time. Instead, I want to address something more concrete: what it actually feels like to build applications with PHP in 2026, and where the ecosystem genuinely stands.

The language is barely the same language

Most of the criticisms of PHP 5.x are still being repeated, but the language has accumulated several layers of substantial improvements since then. The union type, match expression, and nullsafe operator that shipped with PHP 8.0 were not mere syntactic sugar — they were serious investments in the type system. PHP 8.1’s enum and readonly property, PHP 8.2’s readonly class support, and PHP 8.4’s property hook mechanism followed in quick succession.

The code I write in PHP today looks superficially like the code I wrote in 2014, but it is almost a different thing. Type safety is real, value objects can be expressed cleanly, and enum makes the domain layer meaningful. These may look like small additions, but their cumulative effect on the day-to-day experience of building applications is significant.

<?php

// Property hook usage with PHP 8.4
class Money
{
    public function __construct(
        public readonly int $amount,
        public readonly string $currency,
    ) {}

    public int $inCents {
        get => $this->amount * 100;
    }
}

$price = new Money(25, 'TRY');
echo $price->inCents; // 2500

Not what you’d expect from PHP, right? But in 2026, this is ordinary PHP.

Ecosystem health

The number of packages on Composer Packagist surpassed 400,000 in 2024 and continues to grow. PHP’s library ecosystem is more mature and usable than that of many other languages.

On the framework side, Laravel shows no sign of losing its lead. The Symfony ecosystem remains strong in enterprise contexts. Lightweight options like Slim, testing tools like Pest, and a range of well-designed packages are all available. Thanks to Livewire and Inertia.js (a bridge layer for single-page application-style interactions), PHP developers can deliver modern interfaces without having to maintain a separate JavaScript application.

PHP-FPM performance, combined with RoadRunner (a persistent-process PHP runner) and Laravel Octane, reaches genuinely competitive levels. The “PHP is slow” narrative no longer holds for 2026 — properly configured PHP services handle substantial workloads without issue.

Where the “it’s dead” narrative comes from

Some of it is rooted in legitimate historical criticism: the PHP 4–5 era was genuinely messy. register_globals, inconsistent function naming conventions, the lack of a type system — these were real problems. But carrying a language’s past problems into your current decisions is like judging someone by a photograph that hasn’t been updated since 2010.

Some of it comes from ecosystem dynamics. The JavaScript community is loud and prolific. The PHP community quietly ships. The quieter a community is, the less visible it becomes; the less visible something is, the more it gets perceived as absent. This is a perception problem, not a reality problem.

Where PHP is still the right choice

The area where PHP remains strong, in my view, is still web applications and API development. Content management systems, SaaS products, monolithic applications, multi-page applications — in these domains, the PHP ecosystem is competitive on both productivity and long-term maintainability.

If you need low-level system performance in the style of Go or Rust, PHP is not the answer. If you’re building data science or machine learning pipelines, Python is more appropriate. But those are not domains PHP ever claimed to own.

Where I stand

I’ve been writing PHP for over twelve years. During that time I also learned and used Go, Python, and TypeScript. But PHP is still my primary language today. Not out of habit — the maturity and ecosystem depth that PHP offers for application development make it a genuinely practical choice in 2026.

Measuring a language’s value by the volume of news articles or conference talks it generates is the wrong metric. Value is measured by problem-solving capacity and ecosystem health. By that measure, PHP is in a very good place in 2026.

The research behind this post

Laravel's preload curve: 123 files buy eight times what the last 1,912 do

How far can a curated preload take Laravel, and what does each slice cost in start-up time?

Finding

The curve is not proportional to volume. The first 1,592 files — Laravel's own framework — buy 30 ms and add 1.2 seconds to start-up. The next 1,094 Symfony files buy 9.5 ms for free. The **123 files** after that (psr, carbon) buy 15.7 ms, more than the 1,094 before them. And the last 1,912 buy 1.8 ms while adding another 1.2 seconds. So the blanket preload the earlier record measured as a ceiling is the worst point on the curve that is not the origin: stopping at 2,809 files gives 12.77 ms for 1,514 ms of start-up, while 4,721 files ask 2,691 ms to reach 10.96 ms.

measured 16 days ago

High confidence

opcache preload cuts the deploy bill by up to fourteen times — but five of seven frameworks do not hand it to you

With `opcache.preload` on, how long is the first request seven PHP frameworks serve after a deploy, what does the gain cost, and who can actually have it?

Finding

Preload shortens the cold first request by between 3.5× and 14.2×: Symfony drops from 35.58 ms to 2.50 ms, down to Phalcon's bare figure. But only two of the seven candidates — Symfony and CodeIgniter — publish a preload file of their own; for the other five the gain sits on the table waiting for the user to write one. Writing one is not as easy as it looks: a preload generated blindly from the classmap never brings Symfony up at all, and on CodeIgniter it does worse (5.29 ms) than the hand-picked official file (3.13 ms). And the cost does not vanish: Laravel's classmap preload takes the 62 ms it saves each visitor and writes it back as 2,340 ms of php-fpm start-up.

measured 16 days ago

High confidence

The PHP ecosystem does not wait for a new release — but it does not declare support either

After a PHP release ships, when do the 500 most-installed Composer packages declare that they support it, and how much does that declaration actually say?

Finding

43.5% of installs arrive on a constraint with no upper bound at all — `symfony/console` says `>=8.4.1` today, which claims support for PHP 12 as well. Of the 280 packages that do close the top, 247 made the commitment before the version existed: `guzzlehttp/guzzle` covered 8.4 in October 2020, four years early. That leaves 33 packages that genuinely waited, at a median of 325 days. The raw medians fall version over version and read as an ecosystem speeding up; restricted to an equal observation window the trend reverses (238 → 215 → 325 days).

checked 16 days ago

High confidence

The fixed cost of installing a PHP framework: disk size tells you nothing

How many megabytes on disk, how many files per request and how many milliseconds on the first request do seven PHP frameworks cost — and which of those numbers actually predicts throughput under load?

Finding

Disk size predicts nothing: Yii2 has the largest vendor tree at 34.1 MB and loads only 62 files per request, among the fewest in the field. Files per request predicts nothing either: CodeIgniter loads 96 files and serves 6,431 req/s, Symfony loads 224 and serves 13,067. The one number that genuinely separates them is the first request served with a cold opcache: 2.2 ms for Phalcon, 72.2 ms for Laravel — thirty-three times. That is the compile bill the first visitor pays after every deploy, and it is measured in tens of milliseconds, not kilobytes.

measured 18 days ago

High confidence
Service & load Measurement

Seven PHP frameworks under identical load: the gap narrows as soon as the request does real work

On the same hardware, the same PHP build and the same seven routes, how many requests a second do Laravel, Symfony, CodeIgniter, Yii2, Phalcon, Laminas and Slim serve, and at what latency?

Finding

On an empty route the fastest is 4.4× the slowest (Slim 25,975, Laravel 5,966 req/s). As soon as the request does real work the gap closes: 3.7× for a single row from the database, 3.5× for twenty rows. Phalcon is third on an empty route and fifth once a query is involved — being a C extension buys nothing while the process waits on MySQL. And the expensive decision is not the framework: Laravel's own default `web` middleware group takes the same response from 5,858 to 2,176 req/s, so one default costs more than most of the distance between the frameworks.

measured 18 days ago

Medium confidence

Experiments on this topic

Modular PHP libraries that work without being tied to a framework; they became the 39-package InitPHP ecosystem and Framework3.

What it does today

A family of 39 PHP packages — Router, Database, Cache, Mailer, Socket and the rest — each usable standalone or together, all shipped through Composer/Packagist under MIT. Any PHP developer who wants the pieces without buying into a framework can install them today.

Open source PHP Composer PHPUnit
January 2021 — August 2022
Tags: #PHP
Expertise: PHP Developer
Share:

Comments

Sign in with your GitHub account to join the discussion. Comments are stored in GitHub Discussions.

Related Posts

Search the site

Start typing to search posts, projects and pages.

Esc to close Powered by Pagefind