Why TSRX Gives Me PHP Flashbacks

Alex Saft — Fri, 24 Apr 2026 21:54:37 +0000

For the past few days, the frontend community has been buzzing about a potential successor to JSX: TSRX. It was created by Dominic Gannaway(@trueadm) the creator of Inferno & Ripple, and former React and Svelte core team member. It is available today as an Alpha for React, SolidJS, and Ripple.

And Ryan Carniato has already written a detailed piece on it.

I decided to take a look at it myself, and honestly, my feelings are mixed.

On one hand, the problem it tries to solve is painfully familiar. In complex components, JSX can quickly devolve into a spaghetti of {condition && ...}, .map(...), nested callbacks, and a sea of brackets rendering themselves.

At first glance, TSRX feels like a breath of fresh air. Using regular-looking if and for statements right inside the component structure looks much cleaner: a condition looks like a condition, a loop is just a loop, and a block is a block.

However, as someone who writes Solid, I can't shake the feeling that the underlying premise is essentially: "Let's do something very close to what Solid’s model already gives us, but whatever you do, don't call it Solid." Truth be told, Solid's and components already solve a lot of this readability issue. They flatten the dreaded && { staircase. Sure, a dedicated templating syntax might look slightly cleaner in theory, but in practice, and are already perfectly readable.

But here’s my real gripe. The idea of freely mixing component logic and markup triggers some severe PHP flashbacks. I'd love to see actual architectural progress, not just another ride on the pendulum: "Put everything in one file!" → "Let's separate templates for cleanliness!" → "Let's put the logic back into the markup!"

What do you get when you dump HTML, CSS, JS, SQL, and server logic into a single file? You get PHP. Or, depending on how you look at it, a React Server Component. But to quote the wisdom of senior devs who have seen it all: "You really don't want to go down that road."

To be fair, I have a lot of respect for the engineering behind TSRX. As a syntax experiment, it pushes the ecosystem to question some long-standing assumptions, and Ryan’s article makes a strong case for why this direction is worth exploring. We just need to be mindful of the architectural trade-offs we make in the name of better syntax and ergonomics.

The takeaway? By all means, play around with TSRX—it's a fascinating experiment, and I’m really looking forward to seeing how it evolves. But if your goal is to genuinely simplify your templates and frontend logic, it might be time to give Solid a real chance. The beauty of Solid is that it leverages standard semantics. No custom templating languages, no new parsers that you have to somehow duct-tape to your IDE and the TS Language Server, and no extra boilerplate. All you need is your regular editor out of the box. And if TypeScript 7 delivers on the promised performance gains, that setup only gets better.

Who knows, maybe after getting comfortable with Solid's reactive model, you'll decide you still crave that statement-level syntax and give TSRX a spin anyway. And honestly, if you have a blast with that combo — more power to you :)

DEV Community: Alex Saft

Why TSRX Gives Me PHP Flashbacks