[RFC] [Discussion] Native Markup Expressions

On Tue, Jul 14, 2026 at 7:31 PM Liam Hammett
liam+phpinternals@liamhammett.com wrote:

Hi internals,

I'd like to open discussion on a new RFC, "Native Markup Expressions":

RFC: https://wiki.php.net/rfc/native_markup_expressions
Implementation (with tests): https://github.com/php/php-src/pull/22661

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

Cool! I'm reading through it now, and one thing gave me pause:

Any tag whose name is capitalized, contains a namespace separator (), or names a static method (::) is a component; everything else is a literal HTML element.

Not so sure about that heuristic. PSR-4 is not a binding standard on
the language; class names can be lowercase, and therefore should be
valid as a component name. Instead of looking at whether the tag name
is capitalized, I'd think it would be better handled using the
standard fallback resolution strategy: look in the current namespace,
then look at imports, then global/root namespace, and only then
fallback to a literal HTML tag.

--
Garrett W.

That's fair - PSR-4 isn't binding, and lowercase class names are legal
in PHP - it's a real tradeoff. While in theory I agree, I'd note JSX
uses this exact heuristic (lowercase = regular HTML element,
capitalised = component) and it's held up well with the frontend
ecosystem at scale for more than a decade. A few reasons I think it's
the right call here too:

1. Fallback resolution turns typos into silent bugs. With the
   capitalisation rule, <Layuot /> fails loudly with a class-not-found
   error. With fallback resolution, it silently renders as a literal
   <Layuot> element and you find out in the browser, if you find out at
   all.
2. Markup expressions lower to new expressions at compile time.
   Fallback resolution requires knowing whether a class exists, which
   means hitting the autoloader - so tag meaning could no longer be
   decided at compile time. It would also make markup
   load-order-dependent: whether <div> means an element or a component
   would depend on whether any loaded code defines a class named div,
   and defining one later would silently change the meaning of existing
   markup elsewhere.
3. The common case is plain HTML with components sprinkled in. The
   heuristic lets the compiler treat lowercase tags as pure data with
   zero resolution work for a performance boon.

Best regards,
Liam

On Tue, Jul 14, 2026 at 7:31 PM Liam Hammett
liam+phpinternals@liamhammett.com wrote:

Hi internals,

I'd like to open discussion on a new RFC, "Native Markup Expressions":

RFC: https://wiki.php.net/rfc/native_markup_expressions
Implementation (with tests): https://github.com/php/php-src/pull/22661

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

Cool! I'm reading through it now, and one thing gave me pause:

Any tag whose name is capitalized, contains a namespace separator (), or names a static method (::) is a component; everything else is a literal HTML element.

Not so sure about that heuristic. PSR-4 is not a binding standard on
the language; class names can be lowercase, and therefore should be
valid as a component name. Instead of looking at whether the tag name
is capitalized, I'd think it would be better handled using the
standard fallback resolution strategy: look in the current namespace,
then look at imports, then global/root namespace, and only then
fallback to a literal HTML tag.

--
Garrett W.

Hello!

I'm more partial to Edmond Dantes's suggestion of providing parser hooks
https://github.com/true-async/php-src/compare/master...dsl-hooks

Your wish has been granted. 🙂

Here's an article explaining how it works. I didn't spend much time
thinking about the syntax—I simply borrowed it from JavaScript. 🙂
A huge thanks to Kirill for answering countless questions on this topic and
showing me the different approaches PHP has historically used to solve
problems like this.

https://x.com/Edmondif143061/status/2077842921827512720

The performance is expected to be excellent, especially if the parser is
implemented in C.

The generated code is compiled and cached immediately. There is no longer
any need to rely on backdoor techniques to implement features like this.

PHP could easily gain its own LINQ. This would also speed up SQL-like code,
since it would no longer need to be constructed at runtime. Doctrine, for
example, would no longer need to implement complex caching mechanisms to
compensate for that.

If there's anything I can do to help with the RFC, I'd be happy to
contribute.

чт, 16 июл. 2026 г. в 22:51, Morgan weedpacket@varteg.nz:

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:

Heh, just today by coincidence I was pointed toward https://jsx.lol/ -
which, despite the name is more about React in general.

I'm more partial to Edmond Dantes's suggestion of providing parser hooks
so that different markup expression syntaxes can be added via extension,
rather than locking in one that happened to be popular at one time.

I'd also like to point out that, with relatively small changes, PHP could
likely be taught to react to attributes at compile time. That would make it
possible to implement AOP, actors, and many other language extensions based
on macros.

Essentially, what you're seeing here is macros in their purest form the
same concept that exists in Rust today.

чт, 16 июл. 2026 г. в 22:51, Morgan weedpacket@varteg.nz:

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:

Heh, just today by coincidence I was pointed toward https://jsx.lol/ -
which, despite the name is more about React in general.

I'm more partial to Edmond Dantes's suggestion of providing parser hooks
so that different markup expression syntaxes can be added via extension,
rather than locking in one that happened to be popular at one time.