Аргументи за 30 секунд

Чому Lift?

Кожен PHP-фреймворк має свою історію. У Lift вона проста: сучасний PHP заслуговує на фреймворк, не обтяжений рішеннями, ухваленими у 2010 році. Жодного легасі-багажу. Жодної магії. Жодних контейнерів, що важать більше за ваш застосунок.

Ландшафт проблем

Проблема

Типова відповідь

Відповідь Lift

Важкі DI-контейнери

Symfony: потужний, але ~2 МБ скомпільованого кешу ще до запуску вашого коду

Автозв’язування з кешем рефлексії. Жодного кроку компіляції, жодного XML.

Забагато магії

Laravel: фасади, помічники, макроси — ви ніколи не знаєте, що і де виконується

Явні прив’язки. Кожну залежність можна відстежити у вашій IDE.

Підтримка легасі-PHP

Багато фреймворків тягнуть за собою PHP 7.x / глобальний стан / змішані парадигми

Лише PHP 8.1+. Іменовані аргументи, enum, fibers — сучасний PHP усюди.

Рантайм лише під FPM

Традиційні фреймворки перезапускають PHP на кожному запиті, втрачаючи прогрітий стан

Першокласні адаптери RoadRunner, Swoole і FrankenPHP. Нуль змін застосунку.

Розростання залежностей

Slim тягне ~12 пакетів; Laravel піднімає 80+ у свіжій установці

Нуль рантайм-залежностей поза PSR. Ви обираєте кожен доданий пакет.

Важко тестувати

Глобалі, статичні фасади, послідовності завантаження роблять юніт-тести болісними

App::handle($req) — без звернення до глобалей. Чисте тестування вхід/вихід.

Каша з конфігураційних файлів

config/app.php, config/services.yaml, .env, config/packages/…

Один конструктор, один DI-файл. ENV-змінні читаються напряму.

Асинхронність — запізніла думка

Фреймворки на FPM прикручують асинхронність через черги або зовнішні процеси

Адаптери персистентних воркерів — це базовий примітив, а не пакет.

Чим Lift відрізняється

Рантайм-нативний із першого дня

Адаптери RoadRunner, Swoole і FrankenPHP вбудовані у фреймворк — це не пакети спільноти. Кожен рантайм загортає той самий $app у крихітний вхідний скрипт; ваші маршрути, контролери та middleware залишаються байт-у-байт ідентичними.

# загортаємо той самий $app, потім запускаємо сервер
(new RoadRunnerWorker($app))->serve(); → ./rr serve
(new SwooleServer($app))->start(); → php server.php
(new FrankenPhpWorker($app))->serve(); → ./frankenphp run

Пошук статичних маршрутів за O(1)

Статичні маршрути зберігаються у хеш-карті — розв’язання це одне читання масиву, без regex-сканування. Динамічні маршрути відкочуються до скомпільованого regex лише за потреби. Це вимірюється у бенчмарках, а не маркетинговий текст.

Дивитися числа бенчмарків →

Нуль рантайм-залежностей поза PSR

composer require malinichevvv/lift-php встановлює рівно PSR-інтерфейси і сам Lift. Жодного Guzzle, жодних анотацій Doctrine, жодного покинутого пакета, який ви не можете оновити. Ви володієте своїм деревом залежностей.

Тестовний без трюків

$app->handle($request) повертає Response — без суперглобалей, без буферизації виводу, без статичного стану. Кожен обробник тестується ізольовано. Справжні інтеграційні тести, а не ланцюжки замоканого завантаження.

Lift вам підходить, якщо…

▸Ви будуєте REST API, мікросервіс або внутрішній інструмент
▸Вам потрібен рантайм із персистентним воркером (RoadRunner, Swoole, FrankenPHP)
▸Вам потрібна передбачувана продуктивність під навантаженням
▸Ви віддаєте перевагу явним залежностям над магією фреймворку
▸Вам потрібні тести, що перевіряють ваш код, а не налаштування фреймворку
▸Ви програмуєте у парі зі ШІ-асистентом і хочете фреймворк, який він генерує коректно
▸Ви будуєте Telegram/Slack-бота, сервіс вебхуків або ШІ-шлюз

Lift — не той інструмент, якщо…

▸Вам потрібні готовий каркас автентифікації, шаблони Blade або Admin UI «з коробки»
▸Ваша команда очікує досвід «усе включено» у стилі Laravel
▸Вам потрібна велика екосистема власних пакетів (задачі, пошта, сповіщення…)
▸Ви будуєте традиційний серверно-рендерований HTML-застосунок із формами

Готові спробувати?

Робочий JSON-API за 8 рядків. Жодних конфігураційних файлів. Жодних сервіс-провайдерів. Просто PHP.

Почати за 5 хвилин → Повний список можливостей