react-compiler.landing Open editor

react/compiler

React Compiler with Live Diagnostics and Code Analysis

Transform JSX and TypeScript in a worker beside your editor, with diagnostics that quote the file you wrote — and a straight answer about the other thing called the React Compiler.

transformSucrase
runs inWeb Worker
typicalunder 10ms
servernone
Badge.jsx
export default function Badge({ tone, children }) {
  return (
    <span className={`badge ${tone}`}>
      {children}
    </span>
  )
}
compiled in 4ms

01 platform

Two different things are called a React compiler

This is the first thing to settle, because searching for one and finding the other wastes everybody's time. They do unrelated jobs and only one of them runs in a browser.

  • A JSX transform — what runs here

    Turning <div /> into a function call is a syntax rewrite. It has to happen before any React code can execute, and XCODX does it client-side with Sucrase in single-digit milliseconds.

  • The React Compiler — what does not run here

    Meta's optimizing compiler, stable since October 2025, inserts memoisation automatically so you write fewer useMemo and useCallback calls. It needs a full syntax tree at build time and XCODX does not run it.

  • Why the distinction matters to you

    Without a JSX transform nothing runs at all. Without the React Compiler your code still runs correctly — it just memoises manually, the way every React project did before 2025.

  • What you should do about it

    Write useMemo and useCallback where they matter, exactly as you would in any project that has not adopted the compiler. Nothing you write here has to be undone if you adopt it later.

02 pipeline

Every stage a .jsx file passes through

Four stages between saving a file and seeing it render. This is what a JSX compiler does in a browser, and each stage can fail on its own terms — knowing which is which is what makes an error legible.

  1. Parse and transform

    Sucrase rewrites JSX and TypeScript syntax in a single pass. It deliberately skips building a full syntax tree, which is why it is several times faster than Babel — and also why the React Compiler, which needs that tree, cannot ride along.

  2. Resolve imports

    Every import is matched against the project's import map. An installed package resolves to its esm.sh URL; a relative path resolves inside the project. A missing module is named here rather than throwing later.

  3. Render

    The module is handed to React 19 and rendered through createRoot. Where only markup changed, the tree reconciles rather than remounting, which is what preserves component state.

  4. Report

    Transform errors, React dev-mode warnings and console output all arrive in the panel beside the preview, attributed to your source rather than to generated code.

03 deep dive

Reading a transform error

A transform that fails silently is worse than none. Every stage reports against the file you wrote, never against the JavaScript it produced.

Errors carry a line and a column. An unclosed tag or a stray brace points at your .jsx file, on the line you typed it, before anything reaches the runtime.

The stage is named. Knowing whether something failed in the transform or in module resolution tells you where to look, and the two have almost nothing to do with each other.

The previous render survives. A failed compile leaves the last working output on screen with the error beside it, so you keep the thing you were comparing against.

TypeScript annotations are stripped, not checked. That is the same trade a tsc-free dev loop makes locally: types for editing and completion, with a full check in CI where it can take its time.

errors
line + column
stage
named
on failure
last good render kept
types
stripped, not checked
output
Badge.jsx:4:28  transform
  Unterminated JSX contents

  4 |     <span className={`badge ${tone}`}>
    |                             ^

04 features

What the transform handles

The surface below is compiled client-side. If you came here to compile JSX online and see what comes out, this is the scope; anything needing a Node process at build time is out of it.

  • JSX and TSX

    Both go through the same single pass. Renaming App.jsx to App.tsx costs nothing and needs no configuration file.

  • TypeScript annotations

    Types, generics, interfaces and type-only imports are stripped during the transform. Enums and parameter properties are handled too.

  • Modern syntax

    Optional chaining, nullish coalescing, class fields, top-level await and dynamic import() all pass through to a runtime that already supports them.

  • CSS, CSS Modules and SCSS

    Plain CSS, module-style conventions, and SCSS or Sass compiled by Dart Sass in the browser. Utility frameworks install from the npm panel.

  • Any npm package that ships ESM

    Resolved through esm.sh and imported by name via a native import map, so the library you would use locally is the one that runs.

  • React 19, the real runtime

    Actions, useActionState, useOptimistic, use and ref-as-prop all work, because this is React itself rather than a lookalike.

05 workflow

What a compile reports

Four stages, each able to fail on its own terms. This is what the pipeline says on a clean pass and on a broken one.

session
  • save → Badge.jsx
  • transform ok jsx + ts stripped
  • resolve ok 3 imports mapped
  • resolve fail cannot find module 'clsx'
  • Badge.jsx:2:19 — not in the import map
  • npm i clsx → save
  • compiled in 4ms · rendered
  • Each stage reports separately

    A resolution failure is not a syntax failure. Knowing which pass broke narrows the search from the whole file to one line.

  • Positions point at your source

    Line and column refer to the .jsx file you wrote, never to the generated output — code you did not write and should not have to read.

  • A partial failure keeps the last good build

    The previous render stays mounted, so you keep the working version on screen while you fix the broken one.

06 ecosystem

One project, many stacks

A .jsx file can sit beside a .vue one and a Python script; the compiler is chosen per file, not per project.

  • React
  • Vue
  • Angular
  • Svelte
  • SolidJS
  • Lit
  • HTMX
  • Vite
  • TypeScript
  • JavaScript
  • HTML
  • CSS
  • SCSS
  • Less
  • Pug
  • Tailwind
  • Bootstrap
  • Vuetify
  • Ant Design
  • shadcn/ui
  • Phaser
  • Node.js
  • Python
  • Java
  • C++
  • C#
  • Go
  • Rust
  • Ruby
  • PHP
  • Kotlin
  • Swift
  • SQL
  • Bash

07 languages

Everything the editor understands

Highlighting and IntelliSense cover 70+ languages. These are the ones XCODX also compiles or executes for you.

Compiled in your browser11

Zero build step. Transform runs on a Web Worker, so typing never blocks.

  • JSX
  • TSX
  • TypeScript
  • Vue SFC
  • Svelte
  • Angular (JIT)
  • SolidJS
  • SCSS
  • Sass
  • Less
  • Pug

Rendered natively8

Straight to the live preview, no transform in the way.

  • HTML
  • CSS
  • JavaScript
  • JSON
  • Markdown
  • Jupyter (.ipynb)
  • SVG
  • YAML

Executed on demand22

70+ languages run through a self-hosted Piston engine. stdout, stderr, images and tracebacks land in the console.

  • Python
  • Java
  • C
  • C++
  • C#
  • Go
  • Rust
  • Ruby
  • PHP
  • Kotlin
  • Swift
  • Lua
  • Scala
  • Perl
  • Haskell
  • Elixir
  • Dart
  • R
  • Julia
  • SQLite
  • Bash
  • PowerShell

08 questions

Compiling React in the browser — common questions

Questions about the transform itself.

Does the React Compiler work here?

No. Meta's React Compiler — the optimizing pass that inserts memoisation automatically, stable since October 2025 — needs a full syntax tree at build time, and XCODX transforms with Sucrase, which deliberately does not build one. Your code still runs correctly; memoise with useMemo and useCallback as you would in any project that has not adopted it.

Then what compiles my JSX?

Sucrase. It rewrites JSX and TypeScript syntax in a single pass, which is why it finishes in single-digit milliseconds and why the loop stays instant as a file grows. It is the same transform many local dev servers use for speed during development.

Why not use Babel instead?

Babel builds a full syntax tree, which is what makes it powerful for plugins and slow for a keystroke-speed loop. For a dev-time transform the tree buys nothing you can see, and it costs the responsiveness that makes a browser editor worth using.

Does it type-check my TypeScript?

No. Annotations are stripped rather than verified, the same trade a tsc-free dev loop makes locally. You get types for editing and completion; a full check belongs in CI where it can take its time.

How long does a compile take?

Single-digit milliseconds for a typical component, in a Web Worker so the editor never blocks on it. You will usually see the preview update before your hand leaves the keyboard.

Why compile in a Web Worker instead of on the main thread?

Because compilation and typing compete for the same thread otherwise. A large component takes long enough that a main-thread transform drops frames while you type. In a worker the two are genuinely concurrent.

What about React Server Components?

Not compiled here, and no browser-only editor can. Server Components render on a server before the response is sent, so they need a running server process rather than a transform. Everything client-side works normally.

Can I see the transformed output?

The generated module is what the preview runs, and compile errors quote your source with a line and column. This is a working transform in a development loop rather than an inspection tool for its own intermediate output.

Does a failed compile lose my last working preview?

No. The previous render stays on screen with the error beside it, because a blank pane tells you nothing about what changed between the version that worked and the one that did not.

Do I need to install anything to use XCODX Studio?

No. XCODX Studio is a browser-based IDE — the editor, the compilers and the preview all run client-side. There is no download, no package manager to set up and no configuration file to write. Opening the editor is the whole setup step.

Where is my code stored?

In your own browser. Projects, file history and Git objects live in local storage on your device and are never uploaded to a server. That also means XCODX works offline: it is a Progressive Web App, so you can install it and keep coding with no connection.

Is XCODX Studio free?

Yes. The editor, the live preview, the 70+ language runtimes, npm installs, Git and the integrated terminal are all free to use.

Can I use XCODX on a tablet or Chromebook?

Yes. The editor is a responsive web app, so a Chromebook, an iPad or an Android tablet gets the same compilers and the same preview a laptop does — there is no desktop-only build, because there is no build to install at all. The layout adapts to the screen rather than shrinking a desktop UI into it.

Can I export a project or move it to my own machine?

Yes. Export the whole project as a zip with its folder structure intact and open it locally, or commit it and push. It is ordinary source on disk from that point on — no proprietary format and no lock-in, which is also why importing an existing repository from GitHub works the same way in reverse.