Ти колись казав джуну, що добра частина вебу працює на PHP, і бачив, як він мружиться, ніби ти щойно зізнався, що досі їздиш на універсалі 1998 року?

Таке трапляється часто.

Десь в інтернеті раз на пів року хтось публікує черговий пост «PHP мертвий». І раз на пів року половина нових SaaS-дашбордів, інтернет-магазинів, CMS, платіжних флоу та внутрішніх адмінок далі тихо пишеться, масштабується й підтримується на PHP. Прірва між мемом і реальним кодом велика, а у 2026-му вона більша, ніж будь-коли.

Сучасний PHP не той, який усі пам'ятають за своїм першим WordPress-плагіном у 2008-му. Це типізована мова з JIT-компіляцією, атрибутами й багатою екосистемою фреймворків. Вона працює на довгоживучих серверах застосунків, має повноцінні enum'и та readonly-класи, а її інструменти статичного аналізу ловлять більше багів, ніж більшість динамічних мов узагалі здатна собі уявити.

Погляньмо чесно, де PHP насправді зараз.

Проблема репутації старша за теперішню мову

Погану репутацію заробив PHP 4 і ранній PHP 5. Та мова була поблажливою в усьому, в чому не варто. Ти міг викликати будь-яку функцію на будь-якому значенні, мішати логіку й розмітку в одному файлі, зберігати стан у суперглобалах і мовчки ковтати помилки, які мали б завалити запит. У тому PHP mysql_query() і конкатенація рядків були рекомендованим способом спілкуватися з базою, і саме так народилося ціле покоління SQL-ін'єкцій.

Але той PHP перестав бути стандартом багато років тому.

PHP 7 (2015) став тихою революцією: новий рушій, що приблизно вдвічі підняв пропускну здатність, оголошення скалярних типів, типи повернення, оператор spaceship, оператор null coalescing. PHP 7.4 додав типізовані властивості. PHP 8.0 приніс JIT, іменовані аргументи, вираз match, атрибути та constructor property promotion. PHP 8.1 дав нам enum'и, readonly-властивості, fibers, синтаксис first-class callable, intersection-типи. PHP 8.2 додав readonly-класи та DNF-типи. PHP 8.3 додав типізовані константи класів і атрибут Override. PHP 8.4 додав property hooks та асиметричну видимість. PHP 8.5, поточна підтримувана гілка, додав оператор pipe.

Це десять років дисциплінованої еволюції. Кожен реліз додавав щось, чого справді хоче людина, яка любить типи, і водночас лишав мову зрозумілою для того, хто просто хоче викотити фічу до вечора.

Як насправді виглядає сучасний код на PHP

Ось шматок коду, який цілком звичний для PHP-кодбейзу 2026 року:

PHP OrderService.php 
<?php

declare(strict_types=1);

namespace App\Orders;

use App\Pricing\Money;

enum OrderStatus: string
{
    case Pending = 'pending';
    case Paid = 'paid';
    case Shipped = 'shipped';
    case Cancelled = 'cancelled';
}

final readonly class Order
{
    public function __construct(
        public string $id,
        public OrderStatus $status,
        public Money $total,
        public \DateTimeImmutable $createdAt,
    ) {}
}

final class OrderService
{
    public function __construct(
        private OrderRepository $orders,
        private PaymentGateway $payments,
    ) {}

    public function markPaid(string $orderId): Order
    {
        $order = $this->orders->find($orderId)
            ?? throw new OrderNotFoundException($orderId);

        if ($order->status !== OrderStatus::Pending) {
            throw new InvalidOrderTransitionException($order->status);
        }

        $paid = new Order(
            id: $order->id,
            status: OrderStatus::Paid,
            total: $order->total,
            createdAt: $order->createdAt,
        );

        $this->orders->save($paid);

        return $paid;
    }
}

Поглянь, що тут є. Strict types. Enum'и як повноцінні громадяни. readonly-клас, який не можна змінити після створення. Constructor property promotion. Іменовані аргументи. Вираз throw прямо в рядку з ??. Сувора типізація на кожному параметрі й поверненні.

Прочитав один раз, і точно знаєш, що воно робить. Компілятор і статичний аналізатор на кшталт PHPStan теж це прочитають і заздалегідь скажуть, чи ти передав у конструктор не ту форму грошей, чи забув обробити якийсь перехід стану. Це не той PHP, від якого закочують очі. Це мова, яка серйозно до себе ставиться.

Історія з продуктивністю, яку більшість проґавила

Більшу частину свого життя PHP працював за моделлю «процес на запит». Приходить запит, стартує інтерпретатор, виконується твій код, інтерпретатор помирає, наступний запит починає з нуля. Така модель проста в експлуатації (не буває витоків пам'яті між запитами, якщо між запитами взагалі нічого немає), але й повільна, бо кожен запит платить за те, щоб заново збудувати весь світ.

У сучасного PHP є варіанти.

JIT, який з'явився в PHP 8.0 і покращується з кожним релізом, компілює гарячі шляхи коду в нативні інструкції. Найбільше користі від нього на CPU-bound задачах: обробка зображень, математика, парсери. А типовому запиту, який більшість часу чекає на базу, він майже не допомагає. Корисно, але не головна новина.

Більший зсув приносять сервери застосунків, які тримають PHP-процес живим між запитами. RoadRunner (на Go), Swoole (C-розширення, що додає корутини й цикл подій) і FrankenPHP (новіший, побудований на Caddy, з HTTP/3 та early hints із коробки) дають змогу підняти фреймворк один раз, тримати його в пам'яті й обслуговувати тисячі запитів на тому самому теплому рантаймі. У Laravel свій варіант називається Octane.

Коли ти переводиш добре написаний застосунок на Laravel чи Symfony на один із таких рантаймів, пропускна здатність часто зростає в 3-5 разів на тому самому залізі, а для дрібних відповідей іноді й більше. Ти перестаєш платити податок на холодний старт за кожен запит.

Звісно, є нюанс. Довгоживучі процеси означають, що не можна писати код із розрахунком на чистий аркуш. Статичний стан протікає між запитами. Сінглтони ростуть. З'єднання треба акуратно пулити. PHP-спільнота вже кілька років пише під це патерни й інструменти, а великі фреймворки мають повноцінну підтримку режиму «теплого рантайму». Але якщо ти збираєшся деплоїти на FrankenPHP, доведеться писати код так, ніби твій процес житиме тиждень. До речі, саме так завжди працював кожен сервіс на Java, Go чи Node.

Чотиришарова діаграма сучасного стека PHP: можливості мови внизу, далі рантайми, інструменти й фреймворки нагорі

Екосистема не зводиться до Laravel

Якщо у 2014-му ти згадував PHP на співбесіді, наступне питання було, мабуть, «WordPress чи Laravel?». У 2026-му вибір ширший.

Laravel залишається домінантним фреймворком у світі PHP, і цю позицію він заробив тим, що з ним до неможливого приємно працювати. Ергономіка (Eloquent, система черг, broadcasting, хелпери для тестів, CLI artisan) дає маленьким командам відчувати себе великими. Laravel 11 серйозно причесав дефолтний скелет застосунку, а наступні релізи й далі тиснуть на зменшення шаблонного коду. Це дефолтний вибір для нового продукту з нуля.

Symfony грає в довгу: це фреймворк у дусі «збудуймо щось, що буде з нами і за десять років». Його компоненти перевірені боями й перевикористані всюди. Drupal, Magento, частини самого Laravel, Composer і десятки CLI-інструментів залежать від компонентів Symfony. Якщо твоєму кодбейзу потрібна сувора архітектурна дисципліна, береш Symfony.

WordPress досі крутить приблизно два з п'яти публічних сайтів. Можна сперечатися, чи добре це для репутації мови, але з кількістю інсталяцій не посперечаєшся. Екосистема WordPress має власну гравітацію і годує купу PHP-розробників.

Drupal і Magento лишаються актуальними в корпоративних CMS та e-commerce відповідно, обидва працюють на компонентах Symfony.

За фреймворками тихо доросли до світового рівня інструменти для розробників:

  • Composer: менеджер пакетів. Уже багато років він стабільний, надійний і здебільшого нудний, а це найвища похвала, яку може заробити менеджер пакетів.
  • PHPStan і Psalm: статичні аналізатори, які на найвищих рівнях ловлять більше багів, ніж компілятор TypeScript на схожому JavaScript-кодбейзі. Більшість серйозних PHP-команд ганяє їх на кожному PR.
  • Rector: інструмент автоматичного рефакторингу, який може оновити кодбейз з PHP 7.4 до 8.4 за пів дня: type hints, readonly-властивості, enum'и, все підряд.
  • Pest і PHPUnit: закривають тести. Pest дає дружнішу, сучаснішу поверхню; PHPUnit лишається робочою конячкою під нею.

Це серйозна екосистема. Це не мова, що ледь тримається; це мова з глибиною інструментів на рівні будь-якої першокласної бекенд-платформи.

Історія з типізацією реальна

PHP у 2026-му відчувається іншою мовою саме через типізацію. Не тому, що він став статично типізованим (не став і, мабуть, ніколи не стане в тому сенсі, як Java), а тому, що мова тепер дає тобі достатньо інструментів типів, щоб нав'язувати реальні контракти в рантаймі, а статичні аналізатори перетворюють ці типи на гарантії рівня компіляції в CI.

Ти можеш оголосити:

  • Скалярні типи (int, string, float, bool) і типи-посилання (класи, інтерфейси).
  • Union-типи (int|string) та intersection-типи (Countable&Iterator).
  • DNF-типи ((A&B)|C): диз'юнктивна нормальна форма для складених обмежень.
  • Nullable-типи (?int) і самостійні типи null, true, false.
  • Типізовані властивості та типізовані константи класів.
  • Readonly-властивості та readonly-класи.
  • Enum'и з базовими типами (string або int).
  • Property hooks: власна логіка getter/setter без шаблонного коду.
  • Асиметрична видимість: властивість, яку public читати, але private писати.

Додай до цього strict mode (declare(strict_types=1); на початку кожного файлу), і отримаєш мову, прискіпливішу до типів за Python. Додай PHPStan рівня 9 у CI, і отримаєш мову, прискіпливішу до типів за більшість TypeScript-кодбейзів.

Ті, хто не зазирав у PHP з 2015-го, думають, що $x = 'cat'; $y = $x + 1; досі описує мову. Ні, якщо ввімкнути всі перемикачі. А сучасні команди їх вмикають.

То де ж PHP реально доречний у 2026-му?

Там само, де й завжди, тільки з кращою інженерією всередині.

PHP береш тоді, коли треба швидко й маленькою командою викотити вебзастосунок (контент, комерція, SaaS, дашборд, маркетплейс, внутрішній інструмент) і щоб його ще можна було підтримувати за п'ять років. Laravel робить продуктивним перший місяць; можливості мови роблять стерпним п'ятий рік.

Він підходить не для всього. Важкі CPU-навантаження, real-time системи, будь-що, де потрібні глибокі числові бібліотеки: тут ти візьмеш Go, Rust чи Python залежно від того, що оптимізуєш. Більшість команд, які крутять PHP на масштабі, ще тримають пару сервісів іншою мовою для тих частин, де PHP не на місці. Це нормально. Жодна серйозна команда у 2026-му не мономовна.

Але для широкої середини «нам треба серверний застосунок, що обробляє HTTP-запити, працює з базою, шле листи й виконує фонові задачі» PHP у 2026-му справді один із кращих варіантів. Дешево хостити. Достатньо швидко з теплим рантаймом. Спільнота достатньо велика, щоб наймати людей. Система типів достатньо сувора, щоб великі кодбейзи лишалися зв'язними. Фреймворки достатньо зрілі, щоб не винаходити заново авторизацію, черги чи пагінацію.

Мем «PHP мертвий» живе приблизно з часів виходу PHP 5. Він пережив PHP 5, PHP 7, усю серію PHP 8, злет Node, злет Go, злет TypeScript, злет AI-асистованого кодингу й чимало мов, які мали його замінити.

Мем нікуди не дінеться. Як і PHP.