Laravel: чому його полюбили розробники та до чого тут Symfony

Можна щоразу будувати все самостійно. Але на п’ятій реалізації відновлення пароля починаєш підозрювати: можливо, людство вже розв’язало цю проблему.

Laravel став популярним саме навколо цієї потреби — менше повторюваної роботи, коротший шлях до готової функції та приємніший процес розробки. Розберімося, як це сталося і чим його підхід відрізняється від Symfony.

Як усе починалося

У 2011 році Тейлор Отвелл створив Laravel, щоб швидше втілювати власні ідеї вебпродуктів. До цього він працював із корпоративними системами на .NET і COBOL та шукав простіший шлях до створення вебзастосунків. Про цю мотивацію він розповідає в історії Laravel на DigitalOcean.

Symfony з’явився раніше: Фаб’єн Потенсьє відкрив його код у 2005 році. Фреймворк виріс із практичних потреб вебагенції Sensio та досвіду роботи над клієнтськими проєктами. Історія Symfony.

Обидва проєкти починалися з дуже знайомого бажання: перестати виконувати ту саму технічну роботу в кожному новому застосунку.

Розробник хотів заощадити час. Так з’явився фреймворк, який він підтримує роками. Класичний сюжет автоматизації.

Чому Laravel став таким популярним

На нашу думку, головна причина — поєднання зручного старту, узгоджених інструментів і можливості поступово розвивати застосунок.

Laravel пропонує готові підходи до маршрутизації, роботи з базою, черг, кешування та інших поширених задач. Документація об’єднує ці можливості в зрозумілий маршрут навчання. Розробник витрачає менше часу на вибір і поєднання базових деталей. Документація Laravel.

Це впливає на щоденну роботу. Коли потрібно додати нову функцію, команда вже має спільні домовленості та знайомі інструменти.

Зручність також допомагає навчанню: перший видимий результат мотивує розбиратися далі. А коли поруч є приклади, пакети й інші розробники з подібними задачами, рухатися простіше.

Eloquent: база даних людською мовою

Одна з характерних частин Laravel — Eloquent ORM. Вона дозволяє працювати із записами бази через моделі: знаходити, створювати, змінювати та видаляти їх. Модель бере участь і в представленні даних, і в їх збереженні — це підхід Active Record. Документація Eloquent.

Для каталогу послуг, блогу чи адмінпанелі така модель роботи часто дуже природна: отримали статтю, змінили заголовок, зберегли.

Але компактний запис не означає, що можна забути SQL. За красивим зверненням до моделі все одно стоять запити, індекси й обсяг даних.

База не читає ваші наміри. Особливо намір «не робити сто запитів у циклі».

Laravel і Symfony ближчі, ніж здається

Ось поворот сюжету: Laravel використовує компоненти Symfony. Symfony розвивається і як повний фреймворк, і як набір окремих бібліотек, придатних для інших PHP-проєктів. Історія компонентів Symfony.

Тому суперечка «Laravel чи Symfony?» трохи нагадує суперечку двох автомобілістів, які раптом знаходять під капотом деталі одного виробника.

Відмінність — у тому, як фреймворки організовують роботу розробника.

Основні відмінності

Це типові підходи, а не обмеження: Laravel дозволяє будувати модульні системи, а Symfony — компактні застосунки. Механізми встановлення та підтримки описані в документації Symfony Flex, політиці релізів Laravel і переліку релізів Symfony.

Eloquent та Doctrine: хто відповідає за збереження

У типовому проєкті Symfony з Doctrine сутність описує дані й поведінку, а збереженням керує Entity Manager. Це допомагає відокремити об’єктну модель від механізму роботи з базою. Doctrine — окремий проєкт, інтегрований із Symfony, а не його обов’язкова частина. Symfony та Doctrine.

Для простих CRUD-задач підхід Eloquent часто потребує менше кроків. Для складної предметної області поділ відповідальності в Doctrine може бути зручним.

Проте жодна ORM не заважає написати клас на дві тисячі рядків. Тут фреймворки залишають нам небезпечну свободу творчості.

Фасади та явні залежності

Laravel пропонує фасади — короткий доступ до сервісів контейнера через синтаксис, схожий на статичні виклики. Це зручно, але залежності класу можуть бути менш очевидними з його конструктора. Laravel також повноцінно підтримує dependency injection. Документація фасадів.

Symfony робить сильний акцент на сервісах і впровадженні залежностей. Autowiring автоматично підбирає їх за типами, тому явна структура не обов’язково означає ручне налаштування кожного класу. Контейнер Symfony.

Практичне питання тут просте: наскільки легко новій людині зрозуміти, від чого залежить ваш код?

А хто швидший?

Швидше написати функцію і швидше виконати запит — різні речі.

Команда, яка добре знає Laravel, може швидко реалізувати на ньому продукт. Досвідчена команда Symfony може так само ефективно працювати у своєму середовищі.

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

Якщо сторінка робить 300 зайвих SQL-запитів, зміна фреймворку може лише надати проблемі нову структуру папок.

Що обрати для проєкту

Ми б починали з досвіду команди, складності бізнес-логіки та плану підтримки.

Laravel варто розглянути, коли команді близькі його домовленості й екосистема, а проєкт потребує швидкого впровадження типових вебфункцій.

Symfony варто розглянути, коли важливі компонентний підхід, явна організація сервісів і можливість обрати LTS-гілку.

Це не поділ на «маленькі» та «серйозні» проєкти. Обидва фреймворки дають простір для складних систем. Важливо, чи зможе ваша команда зрозуміло розвивати й підтримувати обране рішення.

За що ми цінуємо Laravel

У deweb | space ми цінуємо Laravel за можливість зосередитися на задачах продукту: від керування контентом до отримання заявок та інтеграцій.

Його зручність найкраще працює разом із розумінням PHP, SQL, HTTP та архітектури. Фреймворк бере на себе частину рутини. Рішення про відповідальність класів, поведінку системи та якість коду залишаються за командою.

І це добре. Інакше на code review залишилося б обговорювати лише назви змінних. Хоча дехто й зараз непогано справляється.