Full-stack developer (Symfony, Angular)
Шаблонизатор шаблонизатор ворожнечу. Але в цілому слід виділити загальні завдання. які повинні вирішувати за вас шаблонизатор. З blade не працював і не бачу сенсу є є twig.
Безпека. Це мабуть можна підняти на верх. Типова картина в шаблонах на php - . Частенько це можна зустріти в виведенні інпут, при формуванні помилок пошуку (мовляв "за запитом $ userInput нічого не знайдено. Тобто вставляємо в інпут підключення наших js скриптик, якщо це форма пошуку - ділимося з" другом "і забираємо його сесію. Ну або ще якісь кумедні штуки можна робити. Але ж все дуже просто вирішується. Ставимо якусь функцію, яка за замовчуванням буде фільтрувати XSS ін'єкції при виведенні, і не буде цього робити тільки якщо ми будемо просити Тебе. якщо писати просто на php - з'являються огидні функції, які можна просто забути визват ь. А з шаблонизатор ми пишемо гарні> і можемо спати спокійно.
Допомагають дотримуватися принцип DRY. Сучасні засоби шаблонізаціі (twig наприклад), надають вам можливість розділяти шаблони на блоки, перевикористати їх кілька разів, виділяти макроси, успадковувати шаблони. словом все що завгодно. аби ви могли реюзать шматки html а не копіпаст їх.
Обмежують політ фантазії розробника. Далеко не новина що розробники ледачі засранці. Особливо молоді. Якщо їм в шаблоні раптово знадобилися якісь дані з БД, або дані пов'язані із запитом, більшість не буде паритися і зафігачіть потрібний код прямо в Темпл. Так само деякі грішать тим що частина бізнес логіки розмазують по шаблонах. Так само зустрічав проекти віддані на супорт, де чуваки в шаблонах розбирали через xpath відповіді від сторонньої апішкі (яка використовувалася замість бази даних. Тобто ця справа була розмазано по всьому проекту). Рефакторинг в разі зміни апішкі буде болем.
Хороший шаблонизатор повинен настільки сильно усложініть вам процес написання говнокода в шаблонах, що б ви перехотіли це робити і подумали як це можна зробити нормально. На виході ж ми маємо чистенькі шаблони, які нічого не знаю про бізнес логіці програми та знають тільки про логіку відображення, чого ми і добиваємося взагалі розділяючи логіку від уявлення. Це так само спрощує жити верстальщику (якщо він окремо існує) або вам же в майбутньому при супорті.
З іншого боку, той же twig дозволяє в рамках проекту розширювати синтаксис шаблонізатора, писати екстеншени, словом робити дуже багато кумедних і потрібних речей, що дозволяють скоротити час підтримки шаблонів в майбутньому.
Так як за всі ці приємні речі ми по суті нічого не платимо (шаблонизатор повинен компілювати все це в нативний php так що оверхед просто не буде), чому б не користуватися?
@Radiocity на моїх проектах верстаю я, так що для мене більше синтаксичний цукор без шкоди для продуктивності і безпеки.
А ще я люблю розширювати twig кастомними штуками, правда цим я займаюся на домашніх проектах-концептах. Наприме в голові сидить настирлива думка запив генератор CMS-ок з inline-редагуванням (sir-trevor надихнув і ще пара проектів) з шаблонів на twig. Поки зробив тільки основу для генерації і маршрутизацію (тобто просто зробив компілятор статичних сайтів). До inline-редагування руки не доходять, бо подост вже і інші справи є.
Працював з декількома шаблонизатор, так і не зрозумів, навіщо вони мені потрібні. По суті пих, є сам собі шаблонізатором
Почитайте про можливості, наприклад Twig. Мб проникніться. Цікава штука. Хоча при використанні Volt (читай Twig) є багато булочок і синтаксичного цукру, а також купи додаткових можливостей роботи з шаблонами, але на дрібних проектах їх використання ставиться під сумнів.
Багато хто плутає поняття шаблонизатор. Є на зразок Twig і Smarty зі своїм синтаксисом, роботою з layouts. А є, звичайні PHP-шні з short_tag'амі (@aspetek написав приклад), де ніякого свого "мови" немає, але також розділена логіка.
PHP і інші вебштучкі
Blade з натяжкою можна назвати шаблонізатором, він робить пару простих замін для більш зручного синтаксису, при цьому в шаблоні ви можете відкривати теш