Facebook XHP. Object Templates

Despite the fact that Facebook announced XHP in February 2010, there is still very little information about this template engine, although even as an idea XHP is very interesting.

In this article I will try to give a brief overview of XHP, the main pros and cons, and also address performance issues.

XHP is a PHP extension that complements the syntax of the language, on the one hand, improving the perceptibility of the front-end code and, on the other, helping to avoid XSS attacks. [one]

')

So, what do we need to display some HTML (XML) markup?

If it is rough, the following will be required:

//  HTML $html = '<div id="mydiv"><p>, !</p></div>'; echo $html; 

Now the same thing using XHP:

 $html = <div id="mydiv"><p>, !</p></div>; echo $html; 

or so:

 $html = new :div(array('id'=>'mydiv',), new :p(array(), ', !')); echo $html; 

I think that after these examples, it has already become clear to the majority that “XML” is translated by the XHP extension into certain classes that describe the html-element.
In this, by and large, is the whole essence of the XHP template engine. Now you are not working with "string HTML". From the word "absolutely", since each node is an object with its own properties.

In addition to everything, any user content is screened, i.e. for any non-html-element child, htmlspecialchars is automatically processed. Yes, and your content received from the database will also be shielded by default, believe me, this is better for you.

PHP:

 $html = "<div>{$_POST['xss_content']}</div>"; //   

XHP:

 $html = <div>{$_POST['xss_content']}</div>; //  

Another feature coming from the nature of XHP is HTML (XML) built-in validation. You cannot instantiate a class like this:

 $html = new myHtml(; 

This means that you can’t leave unclosed, with the wrong nesting html-elements can't (short tags are supported).

Now for the cons

The only obvious drawback of the above scheme is that from which its advantages flow - each element is an object .
Accordingly, the layout of the 2000 nested tags is 2000 nested objects.

What we get at the output is clear:

• Increased memory consumption
• Performance degradation

Increased memory consumption to affect the special meaning in the framework of this article I do not see, because XHP objects are quite simple, and quite a lot of memory is allocated for the process (640 kilobytes will be enough for everyone (s)).
But creating a set of nested objects and converting XHP markup to objects should increase the rendering time. The question is how much?

Fortunately, one Rasmus Lerdorf back in 2010 conducted a comparative analysis of the “rate of fire” of XHP vs PHP native and obtained the following results [2]:

• PHP: ~ 97% degradation (30 rps - 1300 rps)
• PHP + APC: ~ 75% degradation (330rps - 1460 rps)

Since it was a long time ago and the tests were wrong , they turned out to be somewhat synthetic - a tiny HTML fragment (form) was generated, I decided that I needed to carry out comparative tests on HHVM (in which XHP support is embedded out of the box, PHP will have to build a separate module).

Unfortunately, the description of all XHP classes remained in php files (Rasmus wrote that perhaps the problem of poor performance can be partially nihilated by transferring the declarations of base classes to the compiled module), for Hack, the authors propose only to replace <? Php with <? Hh / / decl, so the only hope was on the XHP parser markup itself.

And, of course, for rendering, I did not take 4-5 tags, but a full Layout. The siege settings are similar to those in the example of Rasmus.

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 

Degradation of about 68%. Better than 75%, but still relatively much.
Why "relative"? Because the test "application" consisted only of View, without accessing the database, without business logic and other things.
In reality, it may happen that the performance degradation at the View rendering stage as a percentage will be negligible against the background of the rest of the application.

In the end, the question of choosing one or another template engine remains with the system architect.

Information for review:

1. XHP: A New Way to Write PHP by Facebook
2. A quick look at XHP by Rasmus Lerdorf
3. XHP on GitHub