Skip to main content

Command Palette

Search for a command to run...

Moving Beyond JSX: Why TSRX Caught My Eye

Published
5 min read
Moving Beyond JSX: Why TSRX Caught My Eye
S
Experienced Frontend Tech Lead with a strong focus on Next.js and React, excelling in guiding development teams to create high-quality web solutions. Proficient in leveraging the capabilities of Next.js for server-side rendering and static site generation, paired with extensive expertise in crafting responsive, user-centric interfaces using React. Skilled in promoting effective teamwork, ensuring code quality, and adept at troubleshooting and problem-solving, contributing to continuous innovation and company growth.

It’s been a minute since I posted here, but I recently stumbled across a project that genuinely made me stop and rethink how we write frontend code: TSRX (TypeScript Render Extensions).

If you work with React, JSX is practically second nature. We’ve all accepted its quirks as the cost of doing business. But let's be honest-after years of writing it, the cracks in the JSX developer experience are pretty obvious. TSRX feels like the exact upgrade to JSX we didn't know we were waiting for.

Here is why it stands out when you put it side-by-side with standard JSX:

1. The End of "Ternary Hell" (Native Control Flow) This is probably the biggest daily friction point in JSX. Because JSX forces everything inside the template to be an expression, we can't use native JavaScript statements.

The JSX Way: You want to conditionally render something? You're stuck writing nested ternary operators (condition ? <A/> : <B/>) or chaining logical ANDs (&&). Need to render a list? You have to map over arrays inline (items.map(...)), often leading to messy, hard-to-read "JSX soup."

// The JSX Way
return (
  <div>
    {isLoading ? (
      <Spinner />
    ) : (
      <div>
        {items.length > 0 && (
          <ul>
            {items.map(item => (
              <li key={item.id}>{item.name}</li>
            ))}
          </ul>
        )}
      </div>
    )}
  </div>
);

The TSRX Way: You just write normal code. You can use standard if, else, switch, and for statements directly inside your markup. The mental overhead of translating logic into expressions simply disappears. It looks and reads like standard programming.

// The TSRX Way
return (
  <div>
    {if (isLoading) {
      <Spinner />
    } else {
      <div>
        {if (items.length > 0) {
          <ul>
            {for (const item of items) {
              <li key={item.id}>{item.name}</li>
            }}
          </ul>
        }}
      </div>
    }}
  </div>
);

2. Solving the "Rules of Hooks" Headache We all know the golden rule of React: Don't call Hooks conditionally.

The JSX Way: If you need a hook that only runs under certain conditions, you are forced to extract that logic into a brand new, artificially created sub-component. It fragments your codebase and forces you to context-switch just to satisfy the linter.

// The JSX Way
// You have to create a dedicated wrapper component just to use the hook conditionally
function DetailsWrapper({ id }) {
  const details = useDetails(id);
  return <Details data={details} />;
}

// Inside the parent component:
{showDetails && <DetailsWrapper id={id} />}

The TSRX Way: TSRX uses a smart compiler. If you write an if block and place a Hook inside it, the TSRX compiler handles the heavy lifting behind the scenes, automatically extracting that block into a separate component during the build process. You get the DX of inline conditionals without breaking React's rules.

// The TSRX Way
// Just use the hook inside the condition. The compiler handles the extraction!
{if (showDetails) {
  const details = useDetails(id);
  <Details data={details} />
}}

3. True Co-location (Variables Exactly Where You Need Them)

The JSX Way: If you need to calculate a derived variable for a specific piece of UI, you have to define it at the top of your component, far away from where it's actually used in the return statement.

// The JSX Way
function Product({ price, discount }) {
  // Declared way up here, far from the actual UI
  const discountPrice = price - (price * discount);

  return (
    <div>
      {/* ... lots of other UI components ... */}
      <div className="price-tag">
        ${discountPrice}
      </div>
    </div>
  );
}

The TSRX Way: You can declare block-scoped variables (let or const) right inside your markup blocks. Your logic, structure, and styling live intimately together.

// The TSRX Way
function Product({ price, discount }) {
  return (
    <div>
      {/* ... lots of other UI components ... */}
      {
        // Declared exactly where it is used
        const discountPrice = price - (price * discount);
        <div className="price-tag">
          ${discountPrice}
        </div>
      }
    </div>
  );
}

4. A Better Fit for Agents This structural clarity isn't just great for us; it's a massive win for the way we build software today. When we use Agents like Cursor or Claude to help write or refactor code, context fragmentation is the enemy. Because TSRX reduces the need to artificially split components and keeps logic natively readable, Agents can better understand the component's flow. The resulting code is easier to prompt and generate, and much less prone to AI-induced bugs.

The Verdict TSRX is still in Alpha, so keep it out of your production environments for now. But it compiles down to React, Preact, Solid, or Vue, ships with a solid VS Code extension, and can live side-by-side with your existing .tsx files.

It’s rare to see a tool that fundamentally challenges the way we write templates while actually improving readability. Check out the docs and give it a run locally-it might just change how you look at JSX.