Just came across this RFC. Given I've been maintaining XHP as a functioning PHP extension for years now (not sure if sending links in my very first internals message is going to flag something but it's TJ09/xhp-php-extension on github) I wanted to weigh in on the proposal here.
1.
> Technically, markup must begin at a bare < in operand position, and telling that apart from the comparison and shift operators requires the scanner change described under Backward Incompatible Changes - state no extension can reach. The only route open to an extension is rewriting source text before compilation (the original XHP extension's approach), which shifts line numbers in errors and stack traces and leaves the raw file something token_get_all() - and therefore every tool built on it - cannot tokenize.
The extension takes care to avoid shifting line numbers; the preprocessed code ends up looking quite messy as a result but human readability was I think never the goal for what is functionally an intermediate representation.
> Practically, a syntax lives or dies by its ecosystem. Code using an extension-only syntax cannot be reasonably published to Packagist - it is a parse error on any install without the extension - and no IDE, formatter, or static analyser updates its grammar for syntax that may not exist on a given machine. That chicken-and-egg is part of where XHP for PHP stalled, while the same feature thrived in Hack, where it is part of the language. Shipping in core is what makes markup part of PHP itself: parsers, IDEs, and analysis tools implement it once, and every developer's markup gets the same highlighting, formatting, and static analysis their ordinary code already enjoys.
This, though. This is the big thing. While it is *technically* possible for extensions to add new syntax, it is unreasonable to expect tools to be aware of that syntax. I can absolutely confirm that the biggest point of friction in using XHP today is the fact that static analysis tools like psalm or phpstan can't analyze files, code using XHP cannot be formatted or linted with php-cs-fixer, etc.
2.
One thing I think is missing that is commonly used in both my own XHP code but also various JSX frameworks is the idea of context. That is, the ability to pass data through parts of a tree without explicitly passing it through attributes. Factories/decorators may solve some of the need for this, but they seem to be global, so it doesn't seem possible to inject context into only a single subtree.
3.
> This RFC is deliberately narrower than XHP: it targets HTML specifically, not general XML.
Does this mean that inline SVG is out of the question? It's not uncommon to embed SVG in HTML, but it does often rely on XML features...
-T.J. L
On 7/14/26 7:36 PM, Liam Hammett wrote:
Hi internals,
I'd like to open discussion on a new RFC, "Native Markup Expressions":
RFC: PHP: rfc:native_markup_expressions
Implementation (with tests): [RFC] Native Markup Expressions (JSX in PHP) by imliam · Pull Request #22661 · php/php-src · GitHub
It proposes a native syntax for HTML fragments as first-class PHP expressions,
akin to how the frontend community has adopted JSX, with composition and
escape-by-default output:
class Greeting implements Markup\Html
{
public function __construct(public string $name) {}
public function toHtml(): Markup\Html
{
return <>
<h1 class="title">Hello, {$this->name}!</h1>
<p>Welcome to PHP, where markup is a first-class
expression.</p>
</>;
}
}
echo <Greeting name="Rasmus" />; // rendered HTML, values escaped
Despite appearances, this is not a template language grafted onto the engine -
the syntax is pure compile-time sugar. Every markup expression lowers
during compilation to a plain `new` expression:
$html = <button class="btn">Sign in</button>;
// compiles to exactly:
$html = new \Markup\Element('button', ['class' => 'btn'], ['Sign in']);
The RFC already answers many anticipated questions, and I am open
to making further adjustments so this can become a feature the whole
community benefits from.
Looking forward to your feedback.
Best regards,
Liam
is a component; everything else is a literal HTML element.