Facebook XHP. Object Template

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

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


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



    So, what do we need to output a bit of HTML (XML) markup?

    If rude, then the following will be required:
    // генерируем HTML
    $html = '

    Привет, Хабр!

    '; echo $html;


    Now the same thing using XHP:
    $html = 

    Привет, Хабр!

    ; 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 most that the XML is translated by the XHP extension into certain classes that describe the html-element.
    This, by and large, is the whole point of the XHP template engine. Now you are not working with "string HTML". From the word “completely”, since each node is an object with its own properties.

    In addition to all, any user-generated content is escaped, i.e. for any non-html-element child, htmlspecialchars is automatically processed . Yes, and your content received from the database will also be escaped by default, believe me, it’s better for you.

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


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


    Another feature that comes from the nature of XHP is the built-in HTML validation (XML). You cannot instantiate a class this way:
    $html = new myHtml(;
    

    So html-elements can't be left unclosed, with incorrect nesting (short tags are supported).

    Now about the cons


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

    What we get on the output is clear:
    • Increased memory consumption
    • Performance degradation


    I don’t see the increased memory consumption affecting much of this article, because XHP-objects are quite simple, and a lot of memory is allocated for the process (640 kilobytes is enough for everyone (s)).
    But creating a lot of nested objects and converting XHP markup to objects should increase rendering time. The question is how much?

    Fortunately, someone in 2010 Rasmus Lerdorf conducted a comparative analysis of the "rate of fire" of XHP vs PHP native and received the following results [2]:

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


    Since this was a long time ago and the tests were somewhat synthetic, the scanty HTML fragment (form) was generated, I decided that I needed to conduct comparative tests on HHVM (in which XHP support is built-in “out of the box”, a separate module will have to be built for PHP).

    Unfortunately, the description of all the XHP classes remained in the php files (Rasmus wrote that perhaps the problem of poor performance can be partially nihilized by transferring the base class declarations to the compiled module), for the Hack authors suggest only replacing And, of course, for rendering I took Not 4-5 tags, but a full-fledged 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 many.
    Why is it relative? Because the test "application" consisted only of View, without access to the database, without business logic and other things.
    In reality, it may turn out that the performance degradation at the stage of View rendering in percentage terms will be insignificant compared to the rest of the application.

    In the end, the choice of a particular template remains with the system architect.

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

    Also popular now: