Pull to refresh

Facebook XHP. Объектный шаблонизатор

Reading time 3 min
Views 8.4K
Несмотря на то, что Facebook анонсировал XHP еще в феврале 2010 года, до сих пор об этом шаблонизаторе очень мало информации, хотя даже как идея XHP весьма и весьма интересен.

В этой статье я попытаюсь дать краткий обзор XHP, основные плюсы и минусы, а также затрону вопросы производительности.


XHP — это расширение PHP, которое дополняет синтаксис языка, с одной стороны улучшая воспринимаемость front-end кода и с другой — помогая избегать XSS-атак. [1]



Итак, что нам нужно, чтобы вывести немножко HTML(XML)-разметки?

Если грубо, то потребуется следующее:
// генерируем HTML
$html = '<div id="mydiv"><p>Привет, Хабр!</p></div>';
echo $html;


Теперь то же самое, используя XHP:
$html = <div id="mydiv"><p>Привет, Хабр!</p></div>;
echo $html;


или так:
$html = new :div(array('id'=>'mydiv',), new :p(array(), 'Привет, Хабр!'));
echo $html;


Думаю, что после данных примеров, большинству уже стало понятно, что «XML» транслируется расширением XHP в некие классы, которые описывают html-element.
В этом по большему счету и есть вся суть XHP-шаблонизатора. Теперь вы не работаете со «строковым HTML». От слова «совсем», поскольку каждая нода -это некий объект со своими свойствами.

Дополнительно ко всему, любой пользовательский контент экранируется, т.е. для любой дочерний элемент, не являющийся html-element автоматически обрабатывается htmlspecialchars. Да, и ваш контент, полученный из базы данных, тоже будет по умолчанию экранирован, поверьте, так лучше для вас.

PHP:
$html = "<div>{$_POST['xss_content']}</div>"; // не безопасно


XHP:
$html = <div>{$_POST['xss_content']}</div>; // безопасно


Ещё одна фича, исходящая из природы XHP — это встроенная валидация HTML(XML). Вы же не можете проинстанцировать класс таким способом:
$html = new myHtml(;

Значит и оставить не закрытые, с неправильной вложенностью html-element'ы не сможете (short tags поддерживаются).

Теперь о минусах


Единственным очевидным минусом вышеописанной схемы является то, из чего проистекают её плюсы — каждый элемент — это объект.
Соответственно layout из 2000 вложенных тэгов — это 2000 вложенных объектов.

Что мы получим на выходе ясно:
  • Повышенный расход памяти
  • Снижения быстродействия


Повышенный расход памяти затрагивать особого смысла в рамках данной статьи не вижу, т.к. XHP-объекты достаточно простые, а памяти под процесс выделяется достаточно много ( 640 килобайт хватит всем (с) ).
Но создание множества вложенных объектов и преобразование XHP-разметки в объекты должно увеличить время рендеринга. Вопрос — на сколько?

К счастью, некто Расмус Лердорф еще в 2010 году провел сравнительный анализ «скорострельности» XHP vs PHP native и получил следующие результаты [2]:

  • PHP: деградация ~97% (30 rps — 1300 rps)
  • PHP+APC: деградация ~75% (330rps — 1460 rps)


Поскольку это было давно и неправда тесты получились несколько синтетические — генерировался мизерный фрагмент HTML (форма), я решил, что нужно провести сравнительные тесты на HHVM (в которую поддержка XHP встроена «из коробки», для PHP придется собирать отдельный модуль).

К сожалению, описание всех XHP-классов так и осталось в php-файлах (Расмус писал, что возможно проблему низкой производительности можно частично нигилировать переносом объявлений базовых классов в скомпилированный модуль), для Hack авторы предлагают лишь заменить <?php на <?hh //decl, поэтому надежда была только на сам XHP-парсер разметки.

И, естественно, для рендеринга я взял не 4-5 тэгов, а полноценный Layout. Настройки siege аналогичны тем, что в примере у Расмуса.

HHVM + XHP
siege -c 3 -b -t30s http://****.ru
Transactions:                   6003 hits
Availability:                 100.00 %
Elapsed time:                  29.54 secs
Data transferred:               8.80 MB
Response time:                  0.01 secs
Transaction rate:             203.22 trans/sec
Throughput:                     0.30 MB/sec
Concurrency:                    3.00
Successful transactions:        6003
Failed transactions:               0
Longest transaction:            0.03
Shortest transaction:           0.00


HHVM + PHP
siege -c 3 -b -t30s http://****.ru
Transactions:                  19583 hits
Availability:                 100.00 %
Elapsed time:                  29.96 secs
Data transferred:              33.22 MB
Response time:                  0.00 secs
Transaction rate:             653.64 trans/sec
Throughput:                     1.11 MB/sec
Concurrency:                    2.99
Successful transactions:       19583
Failed transactions:               0
Longest transaction:            0.02
Shortest transaction:           0.00


Деградация около 68%. Лучше, чем 75%, но всё равно относительно много.
Почему «относительно»? Потому что тестовое «приложение» состояло только из View, без обращения к БД, без бизнес-логики и прочего.
В реальности же может получиться, что деградация производительности на этапе рендеринга View в процентном соотношении будет ничтожной на фоне остальной части приложения.

В конце-концов вопрос выбора того или иного шаблонизатора остаётся за архитектором системы.

Информация для ознакомления:
  1. XHP: A New Way to Write PHP by Facebook
  2. A quick look at XHP by Rasmus Lerdorf
  3. XHP on GitHub
Tags:
Hubs:
+2
Comments 30
Comments Comments 30

Articles