Twig vs Smarty

Question

[zt50]

Привет!

Думаю сменить шаблонизатор со Smarty на что нибудь другое. Думаю над twig'ом или вообще native.
Сравнительных характеристик шаблонизаторов не очень много (одна вроде как на хабре проскакивала), там twig вроде как выигрывает, но я не нашел ни одного вразумительного отзыва о реальном его использовании.

Поделитесь опытом, пожалуйста.

Comments

[Сергей Береснев]

Зачем менять? Есть ли для этого объективные предпосылки?

[zt50]

ну если пишут что скорость выше, то почему нет?

Answer 1

[Владимир Чернышев]

Попробовал twig и в новых проектах отказался от «нативного шаблонизатора», хотя всегда был его горячим сторонником. Основная причина — в twig по умолчанию включено экранирование вывода и {{user.name}} куда короче (и понятней верстальщику), чем <?php echo htmlspecialchars($user->name, ENT_QUOTES, 'UTF-8') ?>. Плюс для удобного использования хелперов и переменных (хотя бы замены htmlspecialchars($user.name, ENT_QUOTES, 'UTF-8') на escape($user-name), а в идеале просто $user->name), требует вторжения в глобальную область видимости, что может привести к трудно улавливаемым глюкам.

Answer 2

[Анатолий]

Мы долго работали со смарти, с дву и еще некими смартиподобными, так как было время когда смарти не развивалось, и мы пытались найти альтернативу. Потом Сделали пару проектов без шаблонизатора вообще, на этом и остановились. Если правильно подойти к этому делу, то, использование пхп как шаблонизатора, это не так уж и затратно, а где-то даже и удобно.

Answer 3

[zizop]

А почему вы не хотите перейти на native? Вид — php-файл собственно.

Comments

[zt50]

ну вот как раз и думаю :)

[zizop]

Надо только грамотно сделать локальные пространства имён в видах. Мне нравится, как это в Zend_View организованно. Единственное тормозит, но я видел где-то статью, в которой автор нашел способ его здорово ускорить.

Answer 4

[Константин Китманов]

PHP как шаблонизатор — это довольно удобно, т.к.:
* полноценный язык;
* заведомо шустрее шаблонизаторов, построенных на его основе;
* не требует поддержки специфического синтаксиса от вашей IDE/редактора;
* его практически все знают. (Если верстальщик не знает хотя бы PHP хотя бы на уровне «скопипастить и подправить», то от него больше проблем, чем пользы).

Но есть и минусы:
* PHP как шаблонизатор преизрядно многословен. Мне лично как фронтендеру не очень весело со всем этим, особенно после шаблонов Django.
* Нет наследования блоков, из-за этого вызов партиалов с передачей нетривиальных параметров выглядит жутко, иногда с кучей html в строковых литералах.

Comments

[Владимир Чернышев]

Главный минус забыли упомянуть при традиционной реализации — верстальщик имеет полный доступ к глобальной области видимости и способен, например, записать в БД всё что пожелает.

[Владимир Чернышев]

блин, оправилось раньше… Никакой «песочницы» стандартными средствами языка не предусмотрено.

[Константин Китманов]

Ну это уж какая-то совсем традиционная реализация. В вьюху надо передавать какой-то ассоциативный массив и не более того.
Ну и — мне, как фронтендеру, совершенно неохота лазить в БД, тем более — чего-то туда писать:)

[TravisBickle]

> заведомо шустрее шаблонизаторов, построенных на его основе;
Враньё. Компилирующие шаблонизаторы не медленее.

[Константин Китманов]

Можно ссылку на тесты?

[Blumfontein]

> Можно ссылку на тесты?
Тесты не нужны. Просто посмотрите, во что компилируется шаблон твига в кэше. Разница с нативным шаблоном только в том, что твиговский скомпилированный хранится в виде класса. Поэтому оверхед шаблонизаторов по сравнению с голым PHP такой же, как оверхед ООП по сравнению с процедурным стилем, т.е. совершенно незначительный.

Answer 5

[zt50]

Ай, да совсем забыл — меня очень смущает что шаблоны на твиге в первую компиляцию шаблона (когда кэша еще нет) компилируются ну оооочень долго, дольше 30 секунд, правда потом, когда скомпилированы все очень быстро и шустро. Спасибо.

Comments

[TheAlien]

У меня ни одного шаблона не компилировалось так долго. Я вообще не замечаю, как они компилятся, т.е. задержек нет. (а можно какую-нить ссылку на инфу про 30 сек или это ваш личный опыт?)

[zt50]

я разобрался — это была трассировка xdebug'a ;)

[Blumfontein]

Что за шаблоны такие у вас, что 30 секунд компилируются? У меня все время почти мгновенно

Answer 6

[RomAndry]

Шаблонизаторы были в почете в свое время, сейчас любой верстальщик знает основы WEB программирования и ему не сложно в шаблонах использовать блоки того же PHP кода.
Но все равно шаблонизаторы рулят и привычка остается.
Посмотрите еще для себя немецкий проект vLIB (прямая ссылка пока не работает)

Answer 7

[bsboris]

+1 за php в качестве шаблонизатора. Самый главный недостаток Смарти (и вообще любого стороннего шаблонизатора) — он добавлят лишнюю сущность в проект. Веб-разработчикам и так надо знать кучу языков (навскидку — html, css, js+фреймворк, sql, серверный язык + фреймворк). Помнить при этом еще и синтаксис шаблонизатора излишне. К тому же, сам php и правда весьма удобен для использования в шаблонах, главное использовать синтаксис вида if(...): endif; вместо if(...) {} (может показаться очевидным, но, например, один знакомый программист любит городить фигурные скобки в шаблонах. Выглдядит кошмарно.)

Comments

[Mirgorod]

А мне наоборот трудно ориентироваться, если нет фигурных скобок. Большинство текстовых редакторов с подсветкой кода, подсвечивают начальную и конечную фигурную скобку и это очень удобно как по мне.

[zizop]

Вообще-то по идее в видах должно быть минимум логики, только логика отображения. Тогда короткий синтаксис php приходится очень кстати. Сам его не любил в своё время, потом понял, что в видах — самое то.

[Владимир Чернышев]

2zizop: <?php echo htmlspecialchars($user->name, ENT_QUOTES, 'UTF-8') ?> это короткий вид? :)

[Павло Пономаренко]

Я бы написал так на Кохане:

<?= Html::chars($user->name) ?>

[TheAlien]

А я твиге я бы сделал так
{{ user.name|e }}

[Sannis]

В идеале должно быть просто

{{ user.name }}

, а модификатор в случае если данные уже проескейплены.

[DevMan]

короткий синтаксис php приходится очень кстати

Короткий синтаксис — зло, дорого обходящееся при отключении его в настройках.

[TheAlien]

2 Sannis: Да, но я отключаю автоэскейпинг. Мне так удобнее.

Answer 8

[Константин Китманов]

Никакой «песочницы» стандартными средствами языка не предусмотрено

Опять же я не знаток PHP, но, если я правильно помню, песочницу вполне реально создать.

Comments

[Владимир Чернышев]

Если шаблон просто инклудить, то никто не помешает вам вместо echo $data['user_name'] использовать, например, echo $admin_password :)

Песочинцу создать реально, но вот накладные затраты на её реализацию могут вполне быть сравнимы с ними у популярных шаблонизаторов.

[Константин Китманов]

Ну а если не сделать mogrify данным, пришедшим от юзера, то можно и инъекцию схлопотать, кто ж спорит. С тем же успехом можно и в шаблонизатор передать тот же $admin_password:)
Надо ж смотреть, что написано, надо проводить code review или хотя бы читать коммиты коллег.

[Владимир Чернышев]

Вот, кстати, хороший довод против нативной шаблонизации — верстальщик может использовать $_POST и т. п. в шаблоне. Если обязанности создателя шаблонов и создателей контроллеров разделены, да ещё верстальщик не имеет прав на запись во что либо кроме */templates, то шаблонизатор или песочница позволяют ограничить круг доступных для верстальщика данных, он, даже если захочет, не сможет манипулировать в шаблоне чем-то кроме того, что ему явно было передано.

[Константин Китманов]

Стремные какие-то у вас верстальщики, простите.

[Владимир Чернышев]

Верстальщик может и не быть членом команды, смотрите, например, bloger.com Не очень разумно было бы, по-моему, давать в подобных системах доступ ко всей платформе.

[Константин Китманов]

кажется, вы в ссылке ошиблись:) Но смысл вашего замечания я уловил. В данном случае — таки да, вы правы.

Answer 9

[Elkaz]

fabien.potencier.org/article/34/templating-engines-in-php — сравнение шаблонизаторов. Советую Twig, по причине того, что он гораздо удобнее любого другого шаблонизатора на РНР, и быстрее (и удобнее) native PHP.

Comments

[Владимир Чернышев]

Быстрее native PHP он не может быть по определению, т. к. написан на нём. Плюс говорят (с), что Blitz не медленнее native PHP, а то и быстрее, т. к. реализован на Си, а синтаксис по определению слабее.

Но мой выбор тоже twig ^)

Answer 10

[criminalist]

На хабре есть пост, Twig на порядок медлительней Smarty, учитывайте этот момент

Comments

[faruniverse]

Почитал этот пост. Провёл те же эксперименты на моноблоке Lenovo: Core i5/4Gb win10x64,
apache 2.4, php 5.6
smarty-3.1.33, twig-2.x
У меня получилось по тестам:
1) вывод переменных (10000) - смарти быстрее на 22% (~0.026 сек.), компиляция по времени одинаково (~3.6 сек).
2) работа циклов (100x10) - смарти быстрее в 2,75-4,67 раза (~0.009-0.004 сек.), компиляция быстрее в 1,7 раза (~0.178 сек.).
3) наследование (цепочка из 100 шаблонов) - смарти быстрее на 40% (~0.05 сек.), но компиляция медленнее в 2 раза (6.7 сек.).
Т.е. смарти проигрывает только в компиляции многоуровневых шаблонов в 2 раза, но это больше академический тест, т.к. обычно есть родитель, к которому подключены несколько дочерних шаблонов (т.е. 2-3 уровня всего), а в тесте была цепочка из "вложенных" друг в друга 100 шаблонов, что крайне редко.
Да и синтаксис у смарти выглядит проще. В общем, нужно смотреть на предполагаемую посещаемость и загрузку сайта, а также частоту обновления контента (страниц), что может приводить к частой перекомпеляции. Так же оговорюсь, что тест повторил на локальном компе с медленным HDD, но на реальном сервере с SSD всё намного быстрее. Поэтому по хорошему сравнение производительности надо проводить на хостинге. Вот такие пирожки.