Вибираємо Yii2 або Laravel

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

Однак, можна досить докладно роз'яснити ті нюанси, які допоможуть у виборі для вивчення або реалізації конкретного проекту. Порівнювати буде Yii2 і Laravel. Я розумію, що це досить холиварная тема, результат якої зазвичай свідчить, що кожен хороший по своєму. Я, як людина працював з обома, спробую роз'яснити свій підхід до вибору фреймворку, і постараюся найбільш об'єктивно показати їх мінуси і плюси.

Відразу попереджу питання про те, чому не розглядаємо Symfony.
Справа в тому, що Symfony більш низькорівневий фреймворк, який частіше беруть для основи у великих проектах, наприклад таких, як написання власного фреймворку для розробки. Його в принципі не можна порівнювати з Laravel і Yii2, так як вони використовують його компоненти в своїх реалізаціях. Symfony — це дуже потужний продукт, що дозволяє гнучко налаштовувати практично будь-яку систему під потреби, але в ньому мало чого можна використовувати в якості готових рішень для дрібних типових завдань. На GitHub можна зустріти безліч бібліотек або розширень написаних для того ж Yii2 або Laravel як раз на Symfony.

Yii2

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

Легко вивчається, низький старт розробки
Має безліч вбудованих рішень для інтерфейсів
Відмінний генератор моделей, контролерів І CRUD

Мінуси

Не дуже гнучке формування роутов
Погано розвивається (вихід нових версій)
Занадто склеєні бібліотеки для frontend'а з backend'ом

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

Легко вивчається. Фреймворк дійсно легко вивчається, і посидівши день два, над невеликим проектом, ви вже починаєте спокійно кодити на ньому. Для початку вивчення замало хорошої літератури російською мовою, але це добре компенсується завдяки гарному довідником англійською. В крайньому випадку Google-перекладач. Зараз порадую, так було раніше. Зовсім недавно, вони оновили свій сайт з гайдами та документацією, і тепер є гайди російською мовою, знаходяться вони тут. Інформація API поки не перекладена, але там нічого складного. Навіть з невеликими знаннями технічного англійської, все досить просто, оскільки там просто описуються методи, що вони приймають, віддають і що взагалі роблять, інформація тут.

Вбудовані рішення інтерфейсів можна описувати цілої невеликий книжкою, але я постараюся коротко. У систему вбудований Bootstrap, на жаль поки третій, і купка власних модулів, які з ним пов'язані.

Можна навіть погано володіти версткою на bootstrap, і при цьому за допомогою вбудованих в Yii2 методів зробити спливаючі модальні діалоги, віконця, що випадають списки, спойлери і т. д.

Ось невеликий приклад, який можна зустріти на цілій купі сайтів, і навіть в офіційній документації Yii2:

use yii\bootstrap\Modal;

Modal::begin([
 'header' => '<h2>Hello world</h2>',
 'toggleButton' => ['label' => 'click me'],
 'footer' => 'Низ вікна',
]);

echo 'Say hello...';

Modal::end();

Даний приклад якраз створює модальне вікно, з заголовком <h2> Hello world </ h2>, кнопкою click me, яка відкриває цей дилогії, з тілом «Say hello ...» і футером «Низ вікна».
Не потрібно писати всякі там 'data-target = "# id-modal"' або подібне, система розставить все це сама. Такі речі в Yii2 - називаються віджетами, які може робити взагалі будь-який програміст, і тягнути будь фронтенд на свою backend - сторону. Але це насправді і мінус, найостанніший про який я говорив вище. Чому це мінус розберемо трохи пізніше, поки про зручність цього всього.

Будь-подібний віджет може викликатися як звичайний клас зі статичним методом, приймати параметри, від яких буде щось залежати в віджеті і закриватися. Є ще способи реалізації віджетів, які не потрібно відкривати і закривати, вони самі це зроблять, їм потрібно тільки передати параметри, від яких буде щось залежати, наведу приклад з сторонньої бібліотеки

// Multiple select without model
echo Select2::widget([
    'name' => 'state_2',
    'value' => '',
    'data' => $data,
    'options' => ['multiple' => true, 'placeholder' => 'Select states ...']
]);

Це приклад з бібліотеки, що дозволяє викликати в уявленнях віджет Select2, від kartik-v, посилання на GitHub.
Ось такий віджет підключає всі скрипти, розмічає input і select і обробляє їх бібліотекою Select2.

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

Генератор моделей, контролерів і уявлень - це окрема річ, але пов'язана з попередньою частково. У Yii2, є якась GUI область, для вибору різних генерацій. Зверніть увагу, у інших фреймів, якщо і є генератори, то, як правило, тільки консольні. Тут є і інтерфейс і дуже зручно користуватися, називається ця краса gii.

На картике видно що вона може. Генератор моделей і CRUD самі частопригождающиеся речі в ній. Моделі генеруються не як у laravel, в інтерфейсі вказується таблиця, назву та розташування класу для моделі, з урахуванням простору імен, програма сама підтягує всі залежності (можна відключити, якщо не потрібні), якщо розставлені foreign key, і «викочується» модель, з усіма властивостями взятими по колонкам таблиці і методами для зв'язки з іншими, якщо вони є.

Зізнаюся чесно, такого генератора, я більше не бачив ніде.

CRUD генерує готові інтерфейси, контролери до них, для управліннями даних у зазначеній йому моделі. Тобто Спочатку потрібно створити модель, а потім робити CRUD генерацію. На виході ви отримаєте відразу готовий інтерфейс з певною адресою, в якому можна заводити нові записи, редагувати і видаляти їх.

Дуже зручно використовувати для створення панелей адміністраторів або яких-небудь дашбордов. Швидко генерується готовий інтерфейс, який потім можна редагувати, і користуватися, призначивши захист роутам шляхом авторизації або інакше. Сам інтерфейс використовує безліч вбудованих віджетів, які теж можна перенастроювати на свій розсуд. Це дійсно швидка розробка систем з інтерфейсами управління даних. Можна досить швидко зробити ділову CMS для потреб конкретного проекту. Моя думка, що це, самий головний плюс Yii2 в порівнянні з іншими фреймворками.

Тепер поговоримо про мінуси. Про них досить коротко, щоб не роздувати статтю до небувалих розмірів.

Не дуже гнучке формування роутов. У контролерах класів для Yii роуты вказуються наступним чином:

/*----*/

   /**
     * Your Annotation
     * @return mixed
     */
    public function actionIndex()
    {

        return $this->render('index', []);
    }
    
/*----*/

Будь-який шлях в контролері повинен починатися зі слова action і з великої літери вказується його адреса, наприклад Index. Якщо написати з двох слів, наприклад actionArticlesList, то шлях вийде наступний: / названіе_контроллера / articles-list. Якщо нам потрібно як то за своїм організувати формування Рауса, є два способи:

Задати правила в конфіги
Написати свій клас для конкретної групи Рауса, і вказати його в конфіги.

Докладно зупинятися на файлі конфігурації не буду, але виглядає це приблизно так:

[
/*---*/
'urlManager' => [
            'enablePrettyUrl' => true,
            'showScriptName' => false,
            'rules' => [
                '<module:\w+>/<controller:\w+>/<action:(\w|-)+>' => '<module>/<controller>/<action>',
                '<module:\w+>/<controller:\w+>/<action:(\w|-)+>/<id:\d+>' => '<module>/<controller>/<action>',
            ],
        ],
/*---*/
]

У rules, якраз вказуються правила. Там і можна вказати свій клас, або придумати свій вияв для роута, про це можна почитати більш детально в офіційній документації.

Другий пункт мінусів, думаю пояснювати особливо не варто. Слід звернути увагу, що Yii2 досі використовує bootstrap-3, і нового за останній час в ньому додалося досить мало.

Ну і останній пункт, який я обіцяв пояснити - це занадто велику склеенность фронтенда з бекендом. Як і писав вище, безліч віджетів та інших рішень, відразу роблять генерацію готових рішень в уявленнях (views). Це добре і швидко, але багато хто з них, викидають скрипти прямо в тіло сторінки, в коді цих віджетів перемішаний php і html, що не дуже добре виглядає і досить проблематично підтримувати такий код.
Такий метод розробки не дозволяє користуватися збирачами типу WebPack, Gulp або іншими. Точніше користуватися можна, але доведеться відмовитися від основної переваги Yii2 - не користуватися генераторами і готовими рішеннями для інтерфейсу. Не застосовувати препарат класи, які дозволяють збирати скрипти і css в assets і тому подібні складнощі. А якщо відмовитися від них, що тоді залишиться? Риторичне питання!
У сучасній розробці все йде до того, щоб якомога далі відокремити frontend від backend, і в цьому плані Yii2 застаріває. Сподіваюся цей мінус досить зрозумілий.

Laravel

Оскільки ми досить детально познайомилися з Yii2, тут можна навести плюси і мінуси для порівняння з попереднім фреймворком Yii2

плюси

Має вбудований складальник скриптів і scss
Вбудований шаблонізатор Blade
Дуже гнучке формування Рауса
Дуже гнучкі можливості для написання REST API
швидко розвивається

мінуси

Великий функціонал працює через фасади і IDE-системи не бачать методів і властивостей в деяких класах, показуючи попередження
Вивчається трохи складніше Yii2
Немає офіційної документації російською мовою
Ні вбудованих генераторів інтерфейсів

Вбудований складальник заснований на WebPack, по суті це надбудова над ним, яка дозволяє легко почати роботу, і збирати frontend НЕ копаючись в огрядних мануалах по WebPack і його налаштування.

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

Приклад міксу:

let mix = require('laravel-mix');

mix.js('resources/assets/js/app.js', 'public/js')
   .sass('resources/assets/sass/app.scss', 'public/css');

У прикладі стандартна конфігурація, яка у вас з'являється відразу після інсталяції фреймворку. Таких міксів там можна створювати скільки завгодно багато, якщо у вас є поділ декількох frontend додатків.

Мікс відразу вміє збирати scss, однофайловий компонент Vue, а так само в нових версіях Laravel, Vue.js йде відразу в постачанні фреймворку.

Шаблонізатор Blade, ніж то сильно нагадує Twig, але синтаксис і принцип роботи трохи інший. Який з них краще не знаю, але я поки не зіткнувся з такими завданнями, які можна реалізувати на Twig і не можна реалізувати на Blade. Єдиний мінус Blade, який я поки бачу, це те, що Twig відомий багатьом, а Blade тільки розробникам Laravel.

Дуже гнучке формування Роута. Механізм дуже схожий на symfony, тільки замість анотацій, використовується окремий файл і фасадний клас Route, з набором статичних методів.

Плюс в порівнянні з Yii2 в тому, що в контролерах методи можуть називатися як завгодно, і самі Рауса теж. Ми пишемо їх в окремій Директорії, і вказуємо поточний роут, якого він типу-запиту (POST, GET і т.д.), і вказуємо на який він йде контролер і метод в контролері. Так само можна задати ім'я, для виведення з нього посилання через шаблонізатор Blade.

Приклад призначення Роута:

/*---*/
Route::get('/dashboard/newsList', 'DashboardController@newsList')->name('dashboard/newsList'); //Запрос GET, его адрес, вторым параметром указывает на контроллер и метод

Route::middleware('auth')->delete('/dashboard/newsList/news/{uuid}', 'APINewsController@DeleteNews'); //Запрос DELETE, требующий авторизации, передающий последним параметром в URL uuid, И направленный на соответствующий контроллер и метод.
/*---*/

У роутинг зручно використовувати middleware, які перед тим як відправити запит на обробку контролера можу перевірити якісь дані і в залежності від них відправити контролера на обробку чи ні. Одним з таких перевірок може бути авторизація користувача в системі. Причому самі middleware можна використовувати як в контролері, так і при оголошенні маршруту в routes.

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

Я не вказав про це в Yii2, але там теж є система управління такими запитами, але як і всі інші роути, налаштовується або через власний клас або через конфіг, що не завжди зручно. У Yii2 є yii \ rest \ ActiveController - який дозволяє швидко настроїть REST FULL API, але він теж не так гнучкий, як хотілося б.

Завдяки такій системі роути, я б вибрав саме Laravel для побудови проекту працює на REST API. Таким чином, в даному пункті я відповів і на наступний плюс «Дуже гнучкі можливості для написання REST API»

Laravel дуже швидко розвивається. Постійно виходять нові версії, які виправляють помилки і недоробки попередніх, швидко підвищуючи ефективність фреймворку. Він напевно самий швидко розвивається фреймворк з тих, що я знаю.

Переходимо до мінусів.

Робота через фасади, більшості великих класів Laravel. Таке складне речення, я поясню! Справа в тому, що в багатьох класах фреймворку використовується динамічне створення властивостей і методів, в залежності від якихось умов.

Простіше навести приклад. Ми оголошуємо клас моделі роботи з базою даних, яка є розширенням стандартного класу Illuminate\Database\Eloquent\Model, в якому немає статичних методів where, select і т. п., але насправді вони є і ними можна користуватися. Ось такі дива. Справа в тому, що такі методи утворюються з так званих фасадів, які зчитують звичайні методи класу і перетворюють їх на статичні. А властивості виходять шляхом звернення до бази даних. Звичайно зручно, що можна з одними і тими ж властивостями працювати і статично і динамічно, але таким чином, виходить що IDE не бачить дані методи і показує попередження про виклик неіснуючих методів. Правда для цієї проблеми є рішення — використовувати IDE-helper, який вирішує проблему. Даю посилання на GitHub. На GitHub досить докладно розписано як з ним працювати і встановлювати.

Пункт «Вивчається трохи сложее Yii2» не можна вважати об'єктивним, так як це особисто моя думка. Мені було досить складно перебудуватися після Symfony і Yii2 на цю магію з фасадами. Однак, якщо добре подумати, я посидівши пару днів над гайдами та мануалами, теж почав потихеньку писати на ньому, вдосконалюючи свої знання та навички.

Мені здається, що якби я почав вивчати спочатку Laravel а потім Yii2, я б сказав, що Yii2 було складніше вивчати, так що тут справа кожного і суб'єктивно. У будь-якому випадку, вивчати їх досить просто обидва.

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

Немає вбудованих генераторів інтерфейсів. Так, це великий мінус в порівнянні з Yii2, але й одночасно є плюсом. Не вийде швидко, натисненням трьох кнопок зробити готовий інтерфейс для роботи з даними, зате легко відокремити фронтенд від бек-ендом і збирати фронтенд, як це тепер прийнято в сучасній розробці.

Генератори в Laravel взагалі далекі від Yii2, але щось вони все-таки можуть. Є генератори консольних команд, які дають готовий каркас для роботи з консоллю, генератори моделей, контролерів та інші. Але на відміну від генераторів Yii2 — вони порожні. Тобто Якщо ми генеруємо модель, вона буде пуста. Потрібно самим вказувати яке поле буде первинним ключем, до якої таблиці вона належить, які має зв'язки і т. д.Дехто каже, що це додає гнучкості, але ж в Yii2 ви теж можете видалити стандартну генерацію і написати свою. Не думаю, що це тема для суперечок. Тут Yii2 безумовно переможець.

Висновок

Отже, ми підібралися до головного питання цієї статті «Який фреймворк вибрати?». Як видно з даного масивного опису основних відмінностей - обидва фреймворка хороші і дійсно гарні по своєму.

Yii2 ми можемо використовувати в тих випадках, коли немає особливо великих вимог до адмінки фронтенда, а проект потрібно зробити красиво і в стислі терміни.

Laravel - коли у нас є особливі вимоги до фронтенду і трохи більше часу на розробку інтерфейсів. А так же при необхідності повного поділу frontend'a від backend'a.

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

Джерело