TSRX Wants to Replace JSX — But at What Cost?

JSX is not beloved. It is tolerated.

Nobody looked at {condition ? <ComponentA /> : <ComponentB />} and thought "yes, this is peak human expression." We write it because it works, because every Stack Overflow answer uses it, because every bootcamp teaches it, and because the entire JavaScript internet has trained itself — and its AI tools — around it. JSX won by inertia as much as merit.

So when something called TSRX shows up claiming to replace it, I want to take that seriously. The Better Stack channel just dropped a breakdown of TSRX — according to the video, it's a syntax layer built by the same person behind Ripple, a newer front-end framework — and after watching it and spending some time in the TSRX docs, I have feelings. Some good, some complicated, and one that I think matters way more than the syntax debate itself.

(Quick transparency note: the video attributes TSRX to "the creator of Ripple," but independently verifying that connection or the creator's identity from what's publicly available right now is tricky. Take that provenance with appropriate skepticism — the syntax itself is real and documented.)

What TSRX Actually Is

The core idea: TSRX is a compiler layer that sits on top of React, Solid, Vue, Preact, and Ripple, and lets you write components that read top-to-bottom like normal JavaScript. No return statement. Native if blocks. for...of loops. try/catch for error boundaries.

Here's the elevator pitch from the video: components are "very linear. So the order that we write the source in is the order of rendering, simply reading from top to bottom."

That's not a small claim. The entire mental model of a React component — "find the return, work backwards from there" — gets replaced with "just... read it." I pulled up a basic TSRX component to try this myself, and the first thing I noticed is that my eyes didn't skip anywhere. I read it like a recipe. That felt weird and then it felt obvious.

Instead of the nested ternary nightmare that every React dev has written at 11pm before a deadline:

{isLoggedIn ? (
  isAdmin ? <AdminPanel /> : <UserPanel />
) : <LoginScreen />}

You get a plain if/else if/else. Readable. Boring. Correct.

Switch statements work the same way — native JavaScript, no wrapper function required. The Better Stack breakdown points out this is "a little more simple than how you would handle this in React where you need a function to use the same pattern," and that's fair. When I first learned React, someone had to explain to me why you needed a self-invoking function inside JSX to use a switch. The answer was technically correct and completely unsatisfying.

The Parts That Made Me Stop

TSRX also has scoped styles baked in — write a style block inside your component, get automatic class hashing, no style leaking. If you've ever debugged a CSS conflict across components, you understand why this exists. In practice it's similar to Vue SFCs or CSS Modules, so it's not novel, but the integration feels clean.

The prop shorthand is a small thing that I genuinely liked: if your prop name and variable name match (which happens constantly with things like onChange), you can just write it once, like JavaScript object shorthand. That's the kind of QOL thing that makes a syntax feel like it was designed by someone who actually writes components every day.

Then there's lazy destructuring for reactive frameworks like Solid and Vue. In those frameworks, if you normally destructure props, you lose reactivity because you're snapshotting values at call time. TSRX adds an & prefix syntax that looks like destructuring but compiles back to property lookups, so signal updates still trigger rerenders. That's a genuinely clever solution to a real footgun — if you've ever been puzzled by a Solid component that wasn't updating when you thought it should, you know exactly the bug this prevents.

The for...of loop for list rendering is where I'm more divided. Replacing .map() with a loop is philosophically coherent — but every React tutorial, every pair-programming session, every AI autocomplete suggestion is going to reach for .map() first. Retraining that reflex takes longer than people admit.

The Hook Hoisting Thing

Here's the one that I kept coming back to. In React, the Rules of Hooks are non-negotiable: no hooks inside conditionals, no hooks after early returns, no hooks inside loops. You learn this rule early and it becomes muscle memory.

TSRX breaks it — or appears to. You can place hooks after conditions or inside loops and they'll work. What's actually happening is that the TSRX compiler hoists every hook to the top of the generated function before React sees it. React still gets a stable call order. You just don't write it that way.

The Better Stack video flags this concern directly: "it's also a feature where we're making the compiler do a lot more behind-the-scenes magic, specifically around a framework. And I think if I was debugging this, I might get a bit lost as to what code is where."

That's the honest version of the tradeoff. And it landed for me, because I've been in debugging sessions where the gap between what you wrote and what runs is the thing that costs you two hours. If your hook is in one place in your source and somewhere different in the compiled output, that gap is real. For experienced React devs, it might be a deal-breaker. For someone just learning? They'll never know the rule they're "breaking," which might actually be fine — or might set them up for confusion later when they have to work in a non-TSRX codebase.

(On error boundaries: the video mentions try/catch for async and error handling, and the compiler resolves this differently per framework — using something like lazy for async loading, though Solid and Preact have their own distinct lazy-loading patterns, so how exactly that maps isn't fully spelled out. Worth checking the TSRX docs for your specific framework. Also worth noting: React 19 introduced new error handling patterns with the use hook, so the React story here is more nuanced than it was a year ago.)

The AI Problem Is Bigger Than It Sounds

The Better Stack video briefly mentions that TSRX might be "too niche and too late when we have AI writing most of our code and the code that AI is good at writing seems to be JSX and React." The presenter even tested it: "I did throw some demos at Claude using TSRX and it did manage to write it well just based on the site's llm.txt."

That's one optimistic data point — and I want to push on this harder, because if you're a dev in 2024 who uses Copilot or Claude for a meaningful chunk of your work (and statistically, a lot of you are), this is the actual adoption question.

LLMs are fluent in JSX because JSX is everywhere in the training data — GitHub repos, Stack Overflow, documentation, tutorials, blog posts. TSRX has a docs site and a handful of repos. The surface area is tiny by comparison. Even if an LLM can write basic TSRX with the right context, it's going to hallucinate less, autocomplete better, and debug more accurately in JSX. That's not a guess — that's just how these models work. The less they've seen something, the shakier they get at the edges.

So the real question for a developer weighing TSRX isn't "do I like this syntax?" It's "am I willing to write more of my code by hand, and debug more of it without AI assist, in exchange for this readability improvement?" For a junior dev or someone early in their React journey, that's a real cost. Time spent fighting tooling is time not spent building things and learning.

Who Should Actually Care About This

Here's where I'll give you a straight read:

If you're learning React right now, TSRX is not the thing to spend your hours on. Get fluent in JSX first. The ecosystem, the jobs, and the AI tooling all assume you know it.

If you're a Svelte or Vue developer who's always found React's JSX constraints annoying, TSRX reads like it was made for you. The linear top-to-bottom flow, the scoped styles, the native JavaScript control flow — that's the vibe.

If you're already using Ripple, you're apparently already living in this syntax and probably already love it.

And if you're someone who's been writing React for years and has strong opinions about how components should be structured — the Better Stack take is honest: "it's personally not for me, but that does not mean it's bad." That's about right. TSRX isn't trying to solve a problem that doesn't exist. The question is whether the solution costs you more than the problem does.

JSX got tolerated into dominance. TSRX is betting that something better-designed can still break through. Whether "better-designed" beats "what Claude already knows how to write" is the actual experiment in progress.

---

Tyler Nakamura is Buzzrag's consumer tech and gadgets correspondent. He also runs a YouTube channel with 250k subscribers where he reviews devices for real budgets. Find him at @tylernakamura.