Writing

JSX is 13 Years Old. Is TSRX the "Clean Break" We’ve Been Waiting For?

A look at TSRX, the JSX pain points it tries to address, and why it may be worth watching even if JSX is not going away soon.

FrontendTypeScriptJSX
A dark editor-style scene comparing dense JSX markup with cleaner TSRX-style UI syntax.

In the world of frontend development, 13 years is an eternity. To put that in perspective: when JSX was first introduced by the React team in 2013, the iPhone 5S was the peak of mobile technology, and we were still arguing over whether CSS-in-JS was a sin.

JSX changed everything. It took the “logic” and the “markup” and smashed them together in a way that felt wrong at first, then eventually felt like home. But let’s be honest, after a decade of staring at nested ternaries and .map() calls, the honeymoon phase is officially over.

Enter TSRX.

It’s a new project that has been getting attention in frontend circles, and it’s making a bold claim: you should not have to “hack” JavaScript logic into your UI.

The “Ternary Hell” Problem

We’ve all been there. You’re building a simple component that needs to show a loading state, an empty state, or a list of data. In JSX, that usually ends up looking like a decoded transmission from an alien planet:

// The JSX we've accepted as "normal"
return (
  <div>
    {isLoading ? (
      <Spinner />
    ) : data?.length > 0 ? (
      data.map((item) => <Card key={item.id} {...item} />)
    ) : (
      <EmptyState />
    )}
  </div>
);

It works, but it’s fragile. One missing parenthesis and your whole build breaks. One misplaced question mark and your UI disappears. We’ve spent years training our brains to parse these nested expressions, but why?

What is TSRX?

TSRX, short for TypeScript Render Extensions, is not a new framework like React or Vue. It’s a syntax evolution. The core philosophy of TSRX is simple: let JavaScript be JavaScript. Instead of forcing you to use expressions like .map() or &&, it allows you to use actual JavaScript statements like if, else, and for...of directly inside your markup.

Here is that same “Ternary Hell” example rewritten in TSRX:

// The TSRX way
return (
  <div>
    if (isLoading) {
      <Spinner />
    } else if (data.length > 0) {
      for (const item of data) {
        <Card {...item} />
      }
    } else {
      <EmptyState />
    }
  </div>
);

Notice the difference? There are no curly-brace injections for every line. No .map() calls just to loop through UI. It looks like standard code.

The Secret Sauce: Framework Agnosticism

If TSRX was just “prettier JSX,” it might not be worth the switch. But the reason it’s interesting is its compiler-first approach.

TSRX is designed as a syntax layer. That means the same authoring style can potentially compile down to different UI runtimes, including:

  • React-style virtual DOM calls
  • Preact-style output
  • Solid-style fine-grained output
  • Ripple-style output
  • Vue-style render output

That hints at something frontend developers have wanted for a long time: UI logic that is less tightly coupled to one framework’s template syntax.

Is it time to ditch JSX?

Before we all go running to npm uninstall react, let’s get real for a second. JSX is not just a syntax; it’s an ecosystem.

Thirteen years of JSX means thirteen years of:

  • Tooling: ESLint, Prettier, and IDE autocomplete that works reliably.
  • Searchability: every common error message has probably been solved before.
  • Muscle memory: most frontend developers can write a .map() in their sleep.

TSRX is still in the early adopter phase. While the developer experience feels like a breath of fresh air, the tooling still has to catch up. You might find yourself fighting with your linter or missing that one niche VS Code extension that makes your life easier.

The Verdict

Is TSRX the “JSX killer”? Probably not this year. But it represents a useful shift in how we think about frontend code.

We are moving away from being only “library specialists” and moving toward being architects who want code to be clean, portable, and easier to reason about.

If you’re tired of the ternary nightmare and want to write UI code that looks more like the rest of your logic, TSRX is definitely a project to watch. At the very least, it’s a reminder that just because we’ve done something one way for 13 years, that does not mean it’s the best way forever.