Первое обращение к ответам здесь и общий фон:
Основная причина, по которой люди используют их, заключается в том, что они обычно делают вещи немного более краткими. Сомнительно, что это всегда чистая выгода. Увеличенная когнитивная нагрузка изучения нового языка и отсутствие гибкости вашего основного языка может в конечном итоге принести больше недостатка, чем предлагается при использовании языка шаблонов. В частности, Twig требует вручную экспортировать в него основные функции PHP. Лучшим языкам шаблонов, которые стремятся быть краткими, было бы лучше вместо расширения PHP с помощью токенизатора.
Автоматическое экранирование - еще одна сомнительная особенность. Для разработчика, который очень плохо кодирует, автоматическое экранирование может быть более безопасным, но в противном случае это ослабляет безопасность, игнорируя его и предполагая, что по умолчанию все будет безопасно в любом контексте. Действительно безопасный движок шаблонов должен знать много о его контексте, иногда это не всегда можно определить, только программист знает, куда что-то идет. Если вам нужно безопасное программирование, вам нужен разработчик, который не зависит от автоматического экранирования, точка. Это также то, что PHP на самом деле может сделать, если вы токенизируете файл PHP, вы можете отделить необработанный текст от PHP и обернуть части PHP в буферизацию вывода, а затем применить любой фильтр, который вам нравится, так что это не исключительная особенность языка шаблонов.
Некоторые движки шаблонов могут облегчить предварительную генерацию, а предварительную компиляцию - быстрее, но этого можно достичь и с помощью собственных шаблонов. Существует необходимость в разборе шаблонов, что часто делает их менее эффективными и усложняет процесс их использования. Добавленные шаблоны сложности представляют значительный. Это часто можно абстрагировать от вас, но в конечном итоге вы будете раздражать вас, например, проблемы с кэшированием (устаревшие записи), проблемы с производительностью, значительно больше трепетания и беспорядка при отладке, больше слоев и больше кода, требующего гораздо большего, что может пойти не так и т. д.
Многие функции, такие как расширение шаблонов, не требуют использования веток для достижения этой цели. Аналогично для таких вещей, как htmlspecialchars, большинство людей создают короткие вспомогательные функции для всех функций, которые они используют очень часто.
Так где же вам определенно использовать языки шаблонов, такие как Twig?
Присмотр за детьми, плохие разработчики, вроде как действителен, хотя я не уверен, что их следует считать разработчиками, если вам нужно использовать что-то вроде ветки, чтобы попытаться сдержать их. Вы также будете смешивать хороших разработчиков и удивляться, почему их заставляют прыгать через обручи, чтобы достичь простых вещей.
Возможно, вы захотите предоставить шаблоны сторонам, над которыми вы хотите работать с HTML, но не раскрывать внутренние компоненты системы и т. Д. Это может быть, например, в случае, если у вас есть CMS, с пользователями, которые могут редактировать шаблоны но не такие, как ваши разработчики. Это связано с вышеизложенным, но это более реальный случай, когда вы можете получить какую-то выгоду, и это может быть оправдано.
Аналогичный случай, когда вы можете использовать шаблоны между системами, в этом случае язык шаблонов может быть переносимым решением. Это может быть не только там, где у вас есть несколько бэкэндов, но и там, где у вас есть необычные архитектурные требования, такие как серверы, обращенные вперед, отображающие представления из данных, полученных в нисходящем направлении. Продолжайте в том же духе, и вам могут потребоваться шаблоны, которые вы можете визуализировать в интерфейсе или бэкэнде. Если вам нужно только отправить данные во внешний интерфейс, потому что он может отображать представления самостоятельно, это может быть более эффективным. Однако вам также может понадобиться откат к бэкэнду по разным причинам.
Другой случай - статический анализ, в том числе на нескольких языках. Большинство языков шаблонируют эффективно путем конкатенации строк и не знают о языке, который вы создаете. В некоторых случаях язык шаблонов может принести пользу, когда вы сможете полностью его проанализировать, язык и HTML. Еще один способ добиться этого - максимально использовать ваши шаблоны с использованием самого HTML-кода для обозначения вещей, как при использовании классов и т. Д., А также тех средств, которые предоставляет HTML, которые могут позволить вам привязать поведение к вещам. Язык шаблонов также может быть более разборчивым, чем PHP, даже если вы не можете анализировать язык, на котором вы используете шаблоны. Это можно использовать для оптимизации или использования шаблонов, которые легче переносить.
Ваш язык действительно не подходит для создания HTML и других языков. PHP является языком шаблонов, поэтому в большинстве случаев использование языка шаблонов делает мало, но влечет за собой значительные трудности. Однако, если вы используете что-то такое, как Java, вы, скорее всего, захотите использовать движок шаблонов. Языки шаблонов - это DSL, но если у вас уже есть DSL, который делает то, что они делают, то это YAGNI.
Сделанный на заказ шаблон. Где у вас есть определенный формат вывода и домен, который значительно выиграл бы от настроенного языка шаблонов. Это зависит от вашего формата вывода.
Все эти случаи специфичны для конкретной ситуации и недостаточно распространены, чтобы язык шаблонов использовался по умолчанию. Языки шаблонов решают эти проблемы только с разным уровнем успеха (например, многие не знают HTML). Если бы я оценил Twig 10 из 10 за то, как хорошо он справляется, каждый в среднем не был бы далеко 5.
Вы можете конвертировать Twig в PHP, но не PHP в Twig. Иногда это может быть полезно, но это сопряжено со значительными затратами, поскольку вы теряете большую гибкость PHP.
Из небольшого количества внутренних органов Twig, которые я подвергал воздействию качества, также было плохим или импортировало плохие стандарты. Например, синтаксический анализатор не поддерживает или, по крайней мере, не поддерживает сохраняющиеся пробелы, когда я впервые попробовал его пять лет назад. У меня был сценарий, в котором мне нужно было провести рефакторинг, а это означало, что я должен иметь возможность анализировать Twig, изменять и выводить его снова, чтобы переписать код в тысячах шаблонов, Twig не поддерживал его, и мне пришлось самому испортить анализатор.
Точно так же я недавно исследовал побег для Твиг. В частности, выделялось экранирование JS, которое поддерживало экранирование строк JS и других странных вещей, а не просто использование json_encode. Скорее всего, пользовательский экранирование, которое вы получите в фреймворках, неверно. Обычно это более надежно и безопасно делать это самостоятельно (если вы знаете о таких вещах, как то, что происходит, если вы JSON кодируете строку, содержащую и шаблонируете ее как литерал javascript без достаточного экранирования, например).
В большинстве случаев сотни, а иногда и тысячи строк магических шаблонных систем и других связанных с ними систем, используемых для спасения, дезинфекции и т. Д., Являются ужасной практикой, пытаясь угадать ваш сценарий или пытаясь удовлетворить все возможные варианты, добавляя больше возможностей для причудливые ошибки, связанные с повреждением данных, повышающие вероятность грубых ошибок в системе безопасности и т. д. Обычно такие вещи можно найти в инфраструктуре, которая может быть заменена одно- или двухстрочной функцией, которая более безопасна. У вас будут и другие глупости, иногда такие, как обработка чего-либо снова и снова на всякий случай, потому что структура наивна в том, что вы делаете, где, как будто вы делаете вещи сами, вы точно знаете, что делаете, и не делаете тогда есть такие вещи, как санация одной и той же строки снова и снова.