

XHP: A New Way to Write PHP (from Facebook) - ashu
http://www.facebook.com/notes/facebook-engineering/xhp-a-new-way-to-write-php/294003943919

======
ivankirigin
XHP rocks so fucking hard, it isn't even funny. It is just so much better than
alternatives.

IMHO, It is the only PHP tool I use at facebook that is better than
alternatives in other languages. I'm looking at you, django templates!

The notation perfectly represents the objects, with no cruft associated with
object oriented programming. That is really rare. You could argue that the
markup syntax is cruft, but it really helps code readability to have two types
of syntax, for code and for markup.

    
    
      $b = <span>quotes and variables</span>;
      $a = <div>omg, I can't "believe" how easy these {$b} are</div>;

~~~
nostrademons
Couple questions:

1\. How is this different from Django filters? Is it that the default is HTML
escaping instead of having to specify the escaping with each template
variable?

2\. How does it handle different escaping contexts? For example, text in html
attributes needs to be escaped differently from text in the body of the
document. Text in URLs or JavaScript has to be escaped differently still, and
often times you have to combine these escapings (eg. a JavaScript onClick
attribute). Is XHP smart enough to recognize these different contexts and do
the right thing, or do you need to fall back to some manual mechanism?

~~~
drusenko
I'm also very interested in how it is able to escape properly... anybody?

~~~
cmelbye
I've skimmed through the docs. Each tag that you can use is a PHP class. It
knows exactly which attributes it can take and it can do some validations on
the attribute values. I'd assume that it knows when there's supposed to be JS
in an attribute value and when there's supposed to be text.

------
jbyers
For me, XHP is far more interesting than HipHop. And I say that as someone who
administers a pile of single-application CPU-bound PHP servers. This
completely and forever changes the templates-vs-just-PHP debate, and I'm glad
-- it's the kind of evolution PHP needs to continue to be taken seriously.

~~~
lanstein
Strangely enough, I'm reading your PHP code just now :)

~~~
jbyers
Heh, which code is that? If it's anything to do with a certain salesforce-like
system at a certain log-searching company, I apologize. :)

~~~
lanstein
No, thank god that (salesforce-like system) is dead :) Something called
'spacecake'...

~~~
jbyers
I'm happy to have written code for a system I know nothing about. :)

------
jerf
In a previous job, we used Apache::ASP, which is basically PHP-style <? ?>
tags, only with Perl in the insides. We got an awful lot of mileage out of
simply re-writing the default <?= ?> equivalent to automatically HTML-escape
the contents, and adding a new <?! ?> type thing to pass through the inside
unescaped.

It's less "cool" than this, certainly, but making the default reasonably safe
and forcing you to ask for the dangerous level of output rather than
defaulting to dangerous and having to ask for safe is a lot easier to
implement.

------
brown
The sentiment here seems to be overwhelmingly positive. Call me a cynic, but
this reminds me of "magic_quotes" all over again: a "feature" that tries to
help, but masks the fundamental problem.

~~~
jbyers
What is the fundamental problem it masks?

~~~
commonsense
The separation of presentation and logic.

Anyone who's spent the 1990s coding Perl CGI will tell you just how big of a
step backward this is.

~~~
spoondan
That seems to be unrelated to the concern here (as belied by the grandparent
citing magic_quotes). XHP (like plain PHP, for that matter) can be used in a
way that, for all intents and purposes, separates the concerns of presentation
and logic. It's more a matter of convention than constraint.

~~~
commonsense
> separates the concerns of presentation and logic

WHAT? The explicit purpose of this is to combine the presentation (HTML) and
logic (PHP) layers.

~~~
spoondan
The purpose of a "layer" is not determined by the language it's implemented
in, but by what the code actually does. Code that handles nothing but
presentation is by definition separate from the business logic, even if the
presentation code and business logic are implemented in the same language. It
is trivial to implement this architecture with PHP and even easier with XHP.

------
thorax

      That is, it is impossible to generate malformed webpages while using XHP.
    

While the purist in me thinks this is great if everyone _else_ uses it, the
immense amount of productivity lost when I first started using kid templating
(e.g. <http://turbogears.org/about/kid.html> ) really burned me on this whole
concept.

Sometimes I really do want to make a quick test page without crossing all my
i's and dotting all the t's. Importing non-perfect markup from a designer is a
big pain, too, in this kind of templating system.

And, though it's unfair to say so, some companies do well enough without 100%
valid XML markup: [http://blog.errorhelp.com/2009/06/27/the-highest-traffic-
sit...](http://blog.errorhelp.com/2009/06/27/the-highest-traffic-site-in-the-
world-doesnt-close-its-html-tags/)

~~~
drusenko
Saving 14 bytes per request is something only a very few sites need to think
about...

For the rest of us, clarity and semantically correct code are much more
useful.

~~~
nostrademons
Wasn't there just a thread complaining about how the end tags make HTML so
much more verbose and difficult to read, and that's why people are writing
preprocessors like HAML and XHP? I've found that the code is much _clearer_
when you omit your end tags.

As for semantic correctness - it's in the HTML spec, and every major modern
browser handles it correctly. Sometimes I wonder if Google's the only folks
who actually read the W3C specs, there's been so much cargo-cult advice passed
down between web developers.

The "always close your tags" advice came from the early 2000s, when people
were pushing XHTML as a way to make your HTML pages XML compliant (the big
buzzword back then). It gives essentially no benefit to users, no benefit to
developers, costs you bandwidth, makes your pages slower, and clutters up your
markup.

~~~
seasoup
If you don't close your tags,

<div>foo<a>bar<span>baz box

how can you tell the difference between,

<div>foo<a>bar</a><span>baz</span> box</div>

and

<div>foo<a>bar<span>baz</span> box</a></div>

~~~
jws
The HTML tag closing rules specify they only get closed when they have to be.
So neither of your solutions is correct. It is:

<div>foo<a>bar<span>baz box</span></a></div>

~~~
adelevie
my solution was to merely demonstrate the difference between what a programmer
writes and what gets sent as an http response.

------
jolie
See also: Rasmus Lerdorf's discussion of XHP:
<http://toys.lerdorf.com/archives/54-A-quick-look-at-XHP.html>

"...when you combine XHP with HipHop PHP you can start to imagine that the
performance penalty would be a lot less than 75% and it becomes a viable
approach. Of course, this also means that if you are unable to run HipHop you
probably want to think a bit and run some tests before adopting this."

------
stephen
Scala does basically the same thing with XML:

<http://www.scala-lang.org/node/131>

...although I doubt it does escaping by default. Should be simple enough to
add while you're converting the scala.xml.NodeSeq (iirc) to text.

For an API that required both XML and JSON output, Scala's built-in XML
support had us wishing the JSON version of the API was as easy as the XML
version.

------
andre
I'm going to give it a try, simply because of this: Facebook Lite site was
written entirely with XHP.

------
whalesalad
BTW for those of you interested in installing on Linux, you'll need php5-dev
(so on deb/ubuntu machines a quick apt-get install php5-dev solves it). Run
phpize from the root, then the normal ./configure, make, make install etc...

~~~
bshep
has anyone gotten this to work on OSX?

I get strange errors after I build and add the extension to php.ini

LOG: <http://pastie.org/817528>

~~~
cmelbye
Working perfectly for me on OS X snow leopard. It compiled cleanly.

~~~
bshep
Got it compiled properly now, had to get one of the versions without the
lexer/parser files included.

However I'm still getting 'xhp_a' class not found errors with the basic tests
from the wiki, the same as the other comments in the sibling thread.

It seems to happen on several platforms so its probably a configuration error
somewhere.

Any help would be appreciated.

EDIT: Figured it out. You need to include 'init.php' from 'php-lib' in your
php scripts. I copied the directory from the xhp source to my site directory
and included them from there.

------
fookyong
maybe I've misunderstood, but this seems to advocate mixing inline HTML and
php logic - isn't that a huge step backwards in terms of web software
architecture? I thought we were all using the MVC model by now...

My head just hurts thinking how utterly unmaintainable all that spaghetti code
must be.

~~~
flogic
Not really. You can still separate MVC style. Templates have always had some
display logic, which is ok. What you don't want is intermixed application
logic.

~~~
commonsense
In my opinion this "fuzzy" separation is exactly what frameworks like Django
(and many existing PHP MVC frameworks) tries to avoid - they specifically
disallow things like arithmetic in their templating language for this reason.
As soon as you get more than one person working on a site, you're going to
have an overly ambiguous demarcation point between the presentation and the
logic layers and it's going to wreak havoc on the development process. It will
take an enormous amount of discipline to have a parallel design/code workflow.

Does this offer any benefits to XML comprehension beyond syntactical sugar to
allow echo avoid the use of quotes and to remove the god-awful <?php ?> syntax
(which puts it at par, at the very best, in my opinion)? Does it handle XML
syntax errors gracefully? Can you do native transformations on bound
variables, for example, or do any more sophisticated XML DOM-ish tag
functions? The post doesn't mention anything about any of these issues, which
is where the real advantage would lie. If any of that were possible, you could
put the browser DOM (and validation) one step closer to the application logic.
As far as I can tell this just attempts to ambiguate the VC in MVC, where
Django tries to replace V with T (template).

As far as I'm concerned this only increases the squinty-eyed "WTF" factor
between PHP and other languages.

~~~
flogic
The article claims that it's stored in DOM and can manipulated as such. To me
the big win though is that using this means things should get escaped properly
by default.

~~~
commonsense
I might be crazy but I swear I didn't see that they addressed everyone of my
concerns... wtf?

------
leftnode
Ugh, I dislike this a lot. I'm one of the guys who actually likes PHP, so this
may be a bit skewed, but what's wrong with PHP's existing _alternate_ syntax?
Most people don't know about it, but it's clean and easy to follow:

    
    
      <?php if ( true === $some_value ): ?>
        <div>display this div</div>
      <?php else: ?>
        <div>display this div instead</div>
      <?php endif; ?>
    

This way, you can keep basic logic in your templates (its inevitable and
convenient), it's still PHP (there's endforeach, endfor, endwhile, etc.), and
this method of templating is very clean.

You can now have a class that sets variables through __set(), loads up a
.phtml file, starts output buffering, renders the file with those variables,
and then returns it.

You can extend it further to automatically sanitize output variables for XSS
and whatnot, cache output, etc. This way, you don't need some overly verbose
system like smarty to do what PHP does already. XHP just looks like another
smarty: solving a problem that I really don't think exists.

Edit: Ok, I probably shouldn't say I dislike this a lot, I do love seeing
Facebook sticking with PHP and ultimately helping it out.

~~~
dtjm
That sort of code can get really messy when you have to put PHP code inside
the DIVs.

I think I might like the more concise, readable syntax that XHP offers for
interpolating {$variables} (and any PHP code for that matter).

------
vl
I'm using PHPTal right now to achieve more or less same effects, but it's not
the easiest solution - it becomes a bit cumbersome for long fragments.

XHP looks very promising because it solves one of my problems with PHPTal -
generating complex content in the loop (in PHPTal having multiple conditions
in loop is possible, but not exactly elegant)

For example:

    
    
      <?php
        $list = <ul />;
        foreach ($items as $item) {
          if ($item->bold) {
            $list->appendChild(<li><b>{$item}</b></li>);
          } else if ($item->foobar) {
            $list->appendChild(<li><i>{$item}</i></li>);
          } else {
            $list->appendChild(<li>{$item}</li>);
          }
        }
      ?>

------
shaunxcode
Another awesome example of the lengths people will go to compensate for a lack
of macros.

I would so much rather see (define table (html-table (map [tr (td _)] rows)))

then

$table = <table>; foreach($rows as $row) {
$table->appendChild(<tr><td>{$row}</td></tr>); (assuming this is even
possible?) }

~~~
JoelMcCracken
I was just about to make this comment.

I think one of lisp's adoption problems is that it makes things that are just
simply amazing become commonplace.

------
justinph
Sure, let's take two clusterfucks, php and xml, and smash them together! Great
idea!

(Actually, this looks rather handy.. but there is a certain amount of initial
WTF.)

------
drusenko
very, very cool. i can't wait to dig into this more... it looks like even the
basic examples are cool, but there's lots of stuff under the hood waiting to
be discovered.

~~~
ashu
it is indeed one of the coolest things i have used. the fact that you have all
the HTML stored as objects and available for manipulation makes all kinds of
crazy post-processing (just before rendering) possible.

------
there
seems to me that if they went to the trouble to make it understand xml syntax
and error out on invalid code, they should have just made it auto-close tags.
on pages where there are heavily nested divs and other things, auto-closing
the tags would make the code smaller while still generating valid xhtml and
not bothering the developer with such trivial things.

    
    
         echo <div><strong><em>blah;

~~~
Maascamp
While I understand where you're coming from, I feel like that would result in
incredibly confusing markup and only lead to increased headaches down the
road. I'm glad they left that out.

------
callmeed
This sure would make working with WordPress themes easier.

~~~
blasdel
The useful abstraction might mean that they wouldn't need to be GPLed,
especially if combined with a sane view/template separation (like Django's:
the template just gets a dict as input and nothing else).

------
est
looks like E4X, which security is a problem

<http://sla.ckers.org/forum/read.php?2,20408>

Any code mix operation & data is dangerous. That's all how overflow exp,
injection and XSS works

