Native Markup Expressions: Bringing JSX-Style Syntax to PHP

Host: Alex Chan Hey everyone, welcome back to Allur, the show where we dive deep into the languages and frameworks that power the modern web. I’m your host, Alex Chan. Host: Alex Chan Joining me today is Marcus Thorne. Marcus is a senior staff engineer and a long-time contributor to several high-profile Laravel packages. He’s been following the NME proposal since the very first whispers started circulating in the internal forums. Marcus, it is so good to have you on Allur. Guest: Marcus Thorne Thanks so much for having me, Alex! It’s a wild time to be a PHP developer, isn't it? I feel like every time people say PHP is "done evolving," someone drops a bomb like this. Host: Alex Chan Right? It never sleeps. So, Marcus, let’s start at the very beginning for anyone who hasn’t seen the GitHub threads. What exactly are we talking about when we say "Native Markup Expressions"? Is it just "Blade but in PHP files," or is it something deeper? Guest: Marcus Thorne It’s definitely deeper. So, think about how we currently work in Laravel. You have a `.blade.php` file. You use `@` symbols for directives. It’s a separate parser that eventually compiles down to PHP. Native Markup Expressions—or NME—would actually live *inside* your standard `.php` tags. It’s the idea that `<MyComponent />` wouldn't be a string or a template call; it would be a first-class expression that the PHP engine itself understands. Host: Alex Chan Wait, so I wouldn’t need a separate template file at all? I could just… return a tag from a method? Guest: Marcus Thorne Exactly. Imagine a class method where you’re doing some logic, and then instead of returning `view('component', $data)`, you just write `return <Button color="blue">{$label}</Button>;`. It looks almost identical to React’s JSX, but it’s compiled and executed entirely on the server within the PHP runtime. Host: Alex Chan Okay, I have to play devil's advocate for a second. When I first saw this, my immediate thought was: "Isn't this just going back to 2004 when we used to mix HTML and PHP in one giant, messy file?" You know, the "spaghetti code" era we all fought so hard to escape? Guest: Marcus Thorne (Laughs) Oh, absolutely. That’s the "visceral reaction" most veteran devs have. But there’s a massive difference here. Back in the day, we were just echo-ing strings of HTML. It was messy, it was insecure, and there was no structure. NME is declarative and component-based. It’s not just "spitting out HTML"; it’s invoking objects or functions that represent UI components. It’s actually *more* structured than Blade in some ways because it respects PHP’s type system. If your component expects an integer and you pass a string in the markup, the IDE—or even the compiler—could catch that. Host: Alex Chan That’s actually a really interesting point. The type safety aspect. I think that’s where a lot of the "aha!" moments are happening for people. Because in Blade, it’s kind of a "black box" until it renders, right? Guest: Marcus Thorne Precisely. With NME, because it’s part of the language, your IDE—like PHPStorm or VS Code—would treat those tags as actual code. You’d get auto-completion on props, you’d get refactoring tools. If you rename a component class, it renames it in the markup automatically. That’s a level of developer experience we’ve only really seen in the JavaScript ecosystem until now. Host: Alex Chan So, let's talk about the "why" from a Laravel perspective. We already have Livewire, which is incredibly popular for building interactive UIs without leaving PHP. How does NME fit into that? Is this meant to replace Livewire or help it? Guest: Marcus Thorne Actually, I think it’s the "missing piece" for Livewire. If you’ve ever built a complex Livewire component, you’ve felt that jump between the Class file and the Blade file. If NME becomes a reality, a Livewire component could literally be a single file where the `render` method is just a clean block of markup. It would make the "Livewire feel" even more cohesive. It’s about reducing the cognitive load of switching between different syntaxes. Host: Alex Chan I love that phrase, "cognitive load." Because that's really what slows us down. But Marcus, be honest—how hard is this going to be to actually get into the PHP core? I mean, changing the language's parser to support `<` and `>` tags inside code... that sounds like a massive undertaking. Guest: Marcus Thorne Um, "massive" might be an understatement. It’s a mountain. The PHP internals team is famously conservative about the language's syntax. They want to keep it fast and clean. Adding a secondary parser for markup expressions is a huge technical challenge. There are concerns about performance, and honestly, there's the "identity" concern. Some people feel PHP should stay a "pure" server-side language and leave the UI to other tools. Host: Alex Chan I can imagine the RFC discussions are going to be... spirited, to say the least. Have you seen any particular "struggles" or edge cases in the current proposal? Guest: Marcus Thorne Oh, definitely. One big one is: how do you handle attributes? In PHP, we use double quotes for strings. In HTML, we use double quotes for attributes. How do you escape variables? The proposal suggests using the colon prefix, like `:name="$user->name"`, which Laravel developers will recognize from Blade components. But getting that to play nice with the rest of PHP's tokens is tricky. Actually, another big debate is whether these expressions should return a string or an object. If it returns a "Markup Object," we can do some really cool post-processing or caching. Host: Alex Chan Interesting! So it’s not just about the look of the code, but the underlying data structure. Guest: Marcus Thorne Exactly. And I think that’s what makes this proposal different from just "another template engine." It’s a fundamental shift in how PHP views UI. It treats UI as data, not just as a side-effect of the script. Host: Alex Chan You know, it’s funny. We spent a decade trying to get away from "PHP in HTML," and now we’re trying to put "HTML in PHP." It’s like the industry is a giant pendulum. Guest: Marcus Thorne (Laughs) It really is! But I think we’re swinging back to a better version of it. We’re coming back with all the lessons we learned from React, from component-driven design, and from strict typing. It’s like we’re reclaiming the "Personal Home Page" roots but with professional-grade engineering. Host: Alex Chan I love that. "Reclaiming the roots with professional engineering." Before I let you go, Marcus, for the devs listening who are skeptical—or maybe those who are super excited—what should they be looking out for next? Guest: Marcus Thorne Keep an eye on the discussions in the Laravel ecosystem first. Usually, these things start as experimental packages or forks. There’s actually a project called "PXP" that’s experimenting with a pre-processor to allow this syntax today. If you want to see what it feels like, go play with that. But in terms of the "Official" PHP RFC, that’s a longer road. We’re probably talking a year or more of debate before we see anything in a stable version. Host: Alex Chan PXP. I’ll have to check that out. It’s always the experimental stuff that eventually becomes the standard, isn’t it? Marcus, thank you so much for breaking this down for us. You’ve definitely moved me from "skeptical" to "cautiously optimistic." Guest: Marcus Thorne My pleasure, Alex! It was a blast talking about it. Host: Alex Chan Well, there you have it. Native Markup Expressions. Whether you love the idea of "JSX for PHP" or it makes your skin crawl, you have to admit that the innovation happening in the PHP space right now is incredible. It’s no longer the "legacy" language people like to joke about—it’s a playground for some of the most interesting UI ideas in the industry.