A New Dialect From a Familiar Author
The front-end world does not lack for new abstractions, so a fresh take on JSX would normally warrant a raised eyebrow rather than serious attention. TSRX earns the attention because of who built it. Dominic Gannaway is a former core engineer on both React and Svelte, the creator of the Inferno framework and the Lexical editor framework, and the author of Ripple. When someone with that pedigree calls his new project the spiritual successor to JSX, it is worth understanding what he is actually proposing rather than dismissing it as yet another syntax experiment.
TSRX is a TypeScript language extension for declarative user interfaces, extracted from Gannaway's Ripple framework and deliberately made framework agnostic. The headline capability is that a single .tsrx file compiles down to idiomatic output for React, Preact, Solid, Vue, and Ripple, with more targets promised. Gannaway announced it directly, writing that people should think of it as the spiritual successor to JSX, that it was extracted from Ripple and made framework agnostic, and that it can compile to React, Ripple, and Solid with other frameworks to come. That ambition, one authoring format across rival frameworks, is the genuinely interesting part.
Statements, Not Expressions
The technical heart of TSRX is a change that sounds academic but has real ergonomic consequences. JSX is expression-based, meaning a component's markup is fundamentally an expression that must be returned, which constrains how control flow can be written and forces developers into patterns like ternary operators and array maps for conditional and repeated content. TSRX inverts this by being statement-based. Components use native-feeling control flow constructs such as @if, @for, @switch, and @else, and they do not require an explicit return statement at all.
This is more than cosmetic. The expression-based nature of JSX is the root cause of several long-standing frustrations, including awkward conditional rendering and, notably, the rules that forbid calling hooks inside conditionals. Because TSRX is statement-based, it allows hooks to be used inside conditionals without splitting a component into pieces, removing a constraint that has tripped up React developers since hooks were introduced. Whether developers embrace a new control-flow syntax after a decade of JSX habits is an open question, but the underlying argument, that statements model UI logic more naturally than expressions, is a serious one.
Compile Once, Target Many
The framework-agnostic compilation is TSRX's boldest claim and its biggest risk. The promise is that a developer authors a component once in TSRX and the compiler emits clean, idiomatic code for whichever target framework they choose, with the React output being plain React using hooks, JSX, and function components rather than some opaque runtime shim. If that holds in practice, it offers a tantalizing prospect: shared UI logic across teams and products that have standardized on different frameworks, without maintaining parallel implementations.
The skepticism is warranted by history. Cross-framework abstractions have a long graveyard, because frameworks differ not just in syntax but in their reactivity models, lifecycle semantics, and idioms. Generating output that is genuinely idiomatic for React, Solid, and Vue, each of which thinks about state and updates differently, is a hard compiler problem, and the edge cases are where such projects usually founder. The fact that TSRX compiles to plain, readable framework code rather than a heavy runtime is encouraging, because it means the abstraction leaks in a debuggable direction, but the proof will be in how it handles the messy realities of production components.
Quality-of-Life Beyond Syntax
TSRX bundles several conveniences that signal Gannaway is thinking about the whole authoring experience, not just the control-flow headline. It offers scoped styles with deterministic hashes, addressing the perennial problem of CSS encapsulation in component-based UIs without resorting to a separate styling library. It also includes declarative handling for errors and asynchronous operations, two areas where JSX-based code tends to accumulate boilerplate and inconsistency across a codebase.
These features matter because adoption of a new authoring format is rarely driven by a single marquee improvement. Developers weigh the aggregate of daily friction reduced against the cost of learning something new and the risk of betting on an immature tool. Scoped styles and cleaner async handling are the kind of quality-of-life improvements that, taken together, can tip that calculation. They suggest TSRX is aiming to be a comprehensive authoring layer rather than a narrow syntactic patch, which is the more credible path to actually displacing entrenched habits.
Alpha Software and the Reality of Adoption
It is essential to be clear-eyed about maturity. TSRX is MIT licensed but at an alpha or beta stage, with an evolving specification and APIs that will change. Gannaway has been explicit that it is positioned as a co-existing dialect rather than a wholesale migration, which is the right framing. Nobody should be rewriting a production application in TSRX today, and the project itself is not asking them to. It is inviting experimentation and feedback while the design settles.
For engineering leaders, the practical posture is curiosity tempered by patience. TSRX is worth watching and worth a spike on a side project, because the ideas it embodies, statement-based UI and framework-agnostic compilation, are substantive and could influence the broader ecosystem even if TSRX itself does not become dominant. Good ideas in this space have a way of being absorbed by the incumbents. The honest assessment is that this is a project to monitor rather than adopt, authored by someone whose track record means his bets on UI architecture deserve to be taken seriously.
Our Take
We find TSRX intellectually compelling precisely because it diagnoses real, well-known pain points in JSX rather than inventing problems to solve. The expression-based limitations of JSX, the hooks-in-conditionals restriction, and the awkwardness of conditional rendering are genuine sources of friction that millions of developers navigate daily. A statement-based alternative from an engineer who helped build React and Svelte is not a frivolous proposal, and the framework-agnostic ambition, if realized, would address a coordination problem that costs large organizations real effort.
The sober reality is that the front-end ecosystem is littered with elegant ideas that never achieved escape velocity, defeated by the gravitational pull of incumbent tooling and the high switching costs of established codebases. TSRX faces that same headwind, magnified by its alpha status and the inherent difficulty of cross-framework compilation. Our expectation is that its greatest impact may be indirect, pressuring the major frameworks to address the limitations it highlights, much as earlier challengers pushed React itself to evolve. That would be a worthy outcome even if TSRX never becomes the successor its author envisions.
