This New Syntax Wants To Replace JSX

追加: 2026-05-13

[00:00:00]First we had JSX, then we had TSX, but we've been stuck with these for years now. Can't they be improved? Well, maybe by TSRX. It's kind of the same, but it's different. We don't have a function. We have a component. We have strings for our text. There's a normal if statement in here, and there's also no return statement. So, what is this? Why and should you use it? Let's find out.

[00:00:26]Now, there might be a few of you that have actually seen code like this before, and that's because it's actually brought to you by the creator of Ripple.

[00:00:32]This is a new front-end framework that Richard had covered on this channel 6 months ago. So, subscribe to keep up to date with these things. What they've done is they've extracted the syntax used in Ripple, and they've made it work with React, React, Solid, Vue, and Ripple, of course. And a lot of people were pretty hyped for this. Now, TSRX describes itself as a way to write UI components that stay readable and colloccated. So structure, styling, and control flow live together, and the result stays fully backward compatible with TypeScript. But unless you've used Ripple before, you're probably still a little confused by what that means. So let's go through its features. To start, you use this with TSRX files, which does mean that we need a compiler step, but that is super easy to set up with a V plugin. And there's also other options for other frameworks and runtimes as well. As for the actual components, instead of writing function here, we write component. And this is mostly just a keyword for the compiler itself, but it also makes it clear that this is going to contain some rendering logic.

[00:01:24]I'd maybe consider it a small quality of life improvement. One thing to notice though is that we have no return statement here. And that's because TSRX uses statementbased JSX. So you don't need to return a component tree. You just write your markup wherever you want it to render. This means that we can actually drop in another paragraph tag above this card at the top of the component and it's going to render in where it's written. You can still use a return in a component, but it has to be a bare one and it's only used for early returning. So UI and logic after this is skipped. It's helped me to think of TSRX components as very linear. So the order that we write the source in is the order of rendering, simply reading from top to bottom. But I can also see that this might make it harder to quickly see what a component is rendering. Whereas in something like React, we would just jump straight for the return. Another benefit of statementbased JSX is that we can use a lot more normal JavaScript. For example, conditional rendering is super simple. It is just an if statement with an else- if and else to if you need them. In the conditions, we simply just need to place our JSX as a statement.

[00:02:20]This same shape in React often turns into nested turnaries because in JSX, every branch has to be an expression.

[00:02:26]So, I find that the TSRX version can sometimes read easier, especially when we have a more complex statement. But in the same way, I can also see that this may add more verosity, especially when you just need a simple condition. It's the same story for switch statements as well. You can just use a normal JavaScript switch with your cases and the JSX you want to render for each one.

[00:02:44]This is a little more simple than how you would handle this in React where you need a function to use the same pattern.

[00:02:49]So TSRX is a little cleaner here, but an area that I personally like TSRX less is in list rendering. Here we ditch map and instead we use a for off loop and TSRX has actually extended this loop so we can get the index out as well as a stable identity with the key. Then when you want to skip an item you can simply use continue. So again, it's a bit closer to the vanilla JavaScript flow, but as I said, for me, I've gotten very used to using map, filter, and so on. So I'll probably be sticking to that. And it's also worth noting that you can't use any other loop types like for for in while, and dowhile. It is only four off that this works for. Now, continuing the trend of using normal JavaScript, the way that we do error boundaries in TSRX is with a simple try catch block.

[00:03:28]Nothing fancy and pretty self-explanatory. We can then also use the same try catch block if we need async boundaries. We simply just need to add in a pending block and then write your loading component in there. The compiler actually handles taking this code and resolving it to whatever framework you're using. So in React, Pact, and Solid, this actually uses lazy, and in Ripple, it's the Ripple equivalent. Talking of React specifically, though, the features that we've looked at so far appear to allow us to break one of React's key rules, the rule of hooks. We can now place them after conditions and early returns, and even inside of loops. They will all work as normal. This lets us better colllocate our code to where it's actually needed and the final output doesn't even break the rules. The compiler just quietly hoists every hook to the top of the generated function. So React still sees them in a stable order, but you get to write them where they actually belong. Now, for me, as someone who's used React for years, this is one of the ones that I struggle to get used to. And 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. Next up though, we have lexical scoping. So every nested element is creating its own scope. So we're able to declare a const label in three different div blocks here and they don't collide. There's even one at the top of the function here that nothing is reading. And again, it is not conflicting. The same thing goes for every if, for, switch or try statement.

[00:04:45]Each one has its own scopes. So the variables we declare, the functions we run, and the values we derive, they don't leak into the other scopes. This is another one of those features that's focused on colllocating our code. And again, it makes our components read in a top tobottom linear way. Switching things up now from JavaScript, let's talk about styling. In TSRX, we actually have scope styles. So, you can just place a style block in your component.

[00:05:04]And the CSS that we write in there is scoped only to that component with a unique hash being attached to the class name when it's compiled. So, this card component has a card class. And notice here is also trying to use that card class, but it gets none of the card styling because it has no style block of its own. It doesn't get the style from its parent because it doesn't have that unique cache. If you do want to share styles across components though, TSRX has a style keyword. So the parent passes the style name in with this keyword to a component that accepts class name as a prop and it will make sure that that unique hash that it generates goes along with it. So now notice has the same style as parent. You can also technically use a global selector around your styles to escape the scoping and apply those styles globally, but I think that's going to get a bit messy and you'll lose track of where your styles are coming from.

[00:05:46]Personally, I'm a Tailwind guy through and through, so I probably won't use this feature much and I'll stick to Tailwind. But it's pretty cool nonetheless. Next up, a feature for those of you that have been paying attention. In the code blocks that I've showed, there's been a small difference in the way that text is handled in these statements. The text inside of an element has to be double quoted. We can't just write it in like we can in JSX. You can still use dynamic values, though, and in a line like this one, which is in between two double quoted strings, and TSRx will just simply concatenate this into one string when it compiles. Another option that you have is to simply stick to using a template literal. It gets the same result. For me, this has been one of the paper cuts of using TSRX because I just have so much muscle memory of not using quotes for text. Another textbased feature though is that TSRx can actually handle strings that contain actual HTML markup.

[00:06:31]And you have two ways to render this.

[00:06:33]The first one is by simply using the text keyword, which is going to render in the escape text. So, you can see the literal HTML string. And it's also safe from cross-sight scripting. So, this is useful when you want to guarantee that something is going to be a string. And the source of that string is a little bit ambiguous. you don't necessarily know its type when you're writing this code. The second option is for if you want to render the string as HTML. We can simply use the HTML keyword and this passes it as real HTML, but this feature only works in ripple with view supporting a narrower subset of it.

[00:07:02]Another feature not related to React, but it might be interesting to those of you that are using ripple view or solid is lazy destructuring. If you dstructure props normally in these frameworks, you snapshot each value at cool time and that breaks the per access reactivity.

[00:07:14]So in TSRX you can simply add an amperand before the props and while it looks like dstructuring each binding is actually compiled back to a property lookup where it's used. So the runtime sees each access individually so signal updates still trigger rerenders. So it means that you get to keep the dstructuring ergonomics and the framework keeps its reactivity. The final feature I'll show is a nice and simple quality of life one. Have you ever had a prop where the value that you pass to the prop has the same name as that prop? Most commonly in something like an onchange function. Well, with TSRX, you can actually just write this as shorthand, similar to how we can with JavaScript objects. It's clean and simple. So, overall, TSRX feels like it's attempting to blend normal JavaScript flow back into JSX and also add in a few quality of life improvements. And I like quite a lot of its elements. I genuinely think my main downfall with it is that it's 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. With that being said though, 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, but I still think I'm going to stick to normal React myself. The other downside is it feels like especially for React, this is adding on more compiler magic on top.

[00:08:22]And it's also breaking flows that I've spent years learning. So, it's personally not for me, but that does not mean it's bad. I think people coming from spelt might like this a lot. And if you've used Ripple already, you probably already love this. So, let me know in the comments down below if you do. While you're there, subscribe. And as always, see you in the next one.