mitosis.builder.io

Mitosis is a tool from Builder.io that lets you write a component once in a JSX-like syntax and compile it to run natively in React, Vue, Svelte, Angular, Qwik, and other frameworks. It's aimed at teams building multi-framework design systems who want a single source of truth instead of maintaining parallel component libraries. You'd use it when you need the same component to ship across several frameworks; you wouldn't need it if your project only targets one.

How Mitosis works

You author components in .mitosis.jsx (also referred to as mitosis.jsx in the docs), using a subset of JSX plus hooks like useState imported from @builder.io/mitosis. Mitosis then compiles that source into framework-specific output.

The core idea is a single input, many outputs. The docs show one component — an input bound to a name state value with red text — producing equivalent code for each target:

Each output is idiomatic for its framework rather than a thin wrapper — for example, the Vue version uses ref and @change, while the Qwik version uses useStore and onChange$.

What the source looks like

From the site's example, the Mitosis input is:

import { useState } from "@builder.io/mitosis";

export default function MyComponent(props) {
  const [name, setName] = useState("Steve");
  return (
    <div>
      <input
        css={{ color: "red" }}
        value={name}
        onChange={(event) => setName(event.target.value)}
      />
      Hello! I can run natively in React, Vue, Svelte, Qwik, and many more frameworks!
    </div>
  );
}

Two things to notice: state uses a useState hook imported from Mitosis (not React), and styling is expressed via a css prop rather than a framework-specific style system. Both get rewritten per target — the css prop becomes a scoped class in Vue, an inline styles array in Angular, and useStylesScoped$ in Qwik.

Why teams use it

• One source, many frameworks. You avoid rewriting and re-testing the same component in every framework's syntax.
• Design systems. The stated purpose is building multi-framework design systems "with confidence," so the primary audience is teams maintaining a shared component library consumed by apps on different stacks.
• Native output. Because the compiled code is idiomatic per framework, consumers get normal framework code rather than a runtime shim.

Getting started

The site offers two entry points:

• Get Started — the onboarding path for setting up Mitosis in a project.
• Playground — a browser environment to try writing Mitosis components and see the compiled output without local setup.

If you're evaluating it, the Playground is the fastest way to check whether a representative component from your own design system compiles cleanly to your target frameworks. The real test is whether your most complex components — the ones with tricky state, events, or styling — survive the round trip, since simple examples like the one above are the easy case.

When it's a good fit — and when it isn't

Consider Mitosis if you maintain components that must ship to more than one framework, and the cost of keeping those versions in sync is a real burden.

Skip it if your project targets a single framework, or if your components rely heavily on framework-specific features that don't have a clean cross-framework equivalent. The value of Mitosis comes from the multi-target constraint; without it, you're adding a compilation layer for no benefit.

The site does not list pricing or account requirements on the pages referenced here, so check the Get Started flow directly if licensing or login terms matter to your decision.

Mitosis lets you write a component once in a JSX-like syntax and compile it to React, Vue, Svelte, Qwik, Angular, and other frameworks. The fastest way to start is the online Playground, where you can paste or edit a .jsx component and see the generated output for each target framework without installing anything. If you want Mitosis inside your own project, the official "Get Started" path is to install the Mitosis package and import from @builder.io/mitosis.

Try it in the Playground first

The Playground is the lowest-friction entry point. You write a single component using Mitosis's JSX dialect, and the tool shows you the equivalent source for the frameworks it supports.

A minimal component looks like this:

import { useState } from "@builder.io/mitosis";

export default function MyComponent(props) {
  const [name, setName] = useState("Steve");

  return (
    <div>
      <input
        css={{ color: "red" }}
        value={name}
        onChange={(event) => setName(event.target.value)}
      />
      Hello! I can run natively in React, Vue, Svelte, Qwik, and many more frameworks!
    </div>
  );
}

From this single input, Mitosis produces framework-native output. The same component becomes:

• Vue — a <template> with a ref and scoped <style>
• Svelte — a <script> block with bind:value and a <style> block
• Angular — a @Component with an inline template and styles array
• Qwik — a component$ using useStore and useStylesScoped$

The point of the example is the mapping, not the markup: state (useState), styling (css), and event handlers (onChange) each have a defined translation into every target framework.

What to notice in the compiled output

Reading the generated code teaches you the rules faster than any docs page, because each framework's version shows how Mitosis interprets your input.

Two practical takeaways:

1. Write framework-agnostic logic. Anything you put in the component body should be expressible in all targets. If you reach for a React-only hook or a Vue-only directive, the compiler has nothing to map it to.
2. Let Mitosis own the styling and events. Using css and standard handlers keeps the output consistent; hand-rolled DOM manipulation will not translate cleanly.

Move from Playground to a real project

Once the Playground output looks right, the official "Get Started" flow is the next step. The general shape of it:

1. Install the Mitosis package so you can import @builder.io/mitosis in your source files.
2. Write your components as .jsx (or .lite.tsx) files using the Mitosis syntax shown above.
3. Run the Mitosis CLI/build step to emit the target framework code.
4. Consume the generated output in your React, Vue, Svelte, Qwik, or Angular app.

The exact commands and configuration live in the official Get Started guide, which is the authoritative source for current setup instructions — check it rather than relying on a remembered command, since build tooling changes.

Common sticking points

• Framework-specific APIs don't port. If a component depends on something only React or only Vue provides, expect the compiled version to be incomplete or wrong. Keep shared components to the common subset.
• State and lifecycle are the hard part. Simple props and markup translate reliably; complex effects and refs are where cross-framework compilation gets fiddly. Prototype those in the Playground before committing.
• Verify each target, not just one. A component that compiles cleanly to React may still produce awkward Vue or Angular output. The Playground's side-by-side view exists precisely so you can check all targets at once.

When Mitosis is the right choice

Use Mitosis when you are building a multi-framework design system — a shared component library that has to ship to more than one framework — and you want a single source of truth instead of maintaining parallel implementations. The Builder.io description frames it exactly this way: "Write components once, run everywhere."

It is a weaker fit when you only target one framework, or when your components lean heavily on framework-specific features that have no cross-framework equivalent. In those cases the translation layer adds overhead without buying you portability.

Start in the Playground with the example above, confirm the generated output for the frameworks you actually need, then follow the official Get Started guide to wire Mitosis into your build.

Mitosis is a tool from Builder.io that lets you write a component once in a JSX-like syntax and compile it into native code for React, Vue, Svelte, Angular, Qwik, and other frameworks. You get a single source of truth for a design system, and the compiler handles the framework-specific translation. This page explains the mechanism, using the official example as a reference.

The core idea: one source, many outputs

Instead of maintaining separate component libraries per framework, you write the component in mitosis.jsx using imports from @builder.io/mitosis. The compiler then reads that file and emits equivalent components in each target framework. The logic (state, props, event handlers) and styles are preserved, but the syntax is rewritten to match each framework's conventions.

What the input looks like

The source component uses JSX plus Mitosis primitives such as useState:

import { useState } from "@builder.io/mitosis";

export default function MyComponent(props) {
  const [name, setName] = useState("Steve");
  return (
    <div>
      <input
        css={{ color: "red" }}
        value={name}
        onChange={(event) => setName(event.target.value)}
      />
      Hello! I can run natively in React, Vue, Svelte, Qwik, and many more frameworks!
    </div>
  );
}

Two things matter here: the reactive state (name / setName) and the inline css object. Both need to survive compilation into each framework's own idioms.

How the compiler translates it

The compiler parses the JSX and maps Mitosis constructs onto each target's equivalents:

• State — useState becomes ref in Vue, a class field in Angular, a let binding in Svelte, and useStore in Qwik.
• Event handlers — onChange becomes @change in Vue, bind:value in Svelte, onChange$ in Qwik, and so on.
• Styles — the css={{ color: "red" }} object becomes a scoped class or inline style appropriate to the framework.
• Markup — JSX is rewritten to templates (Vue, Angular, Svelte) or kept as JSX/TSX (React, Qwik).

The same component in each framework

The example shows one source producing five different outputs. The behavior is identical; only the syntax differs.

For example, the Vue output uses ref("Steve") and a scoped .input { color: red; } rule, while the Qwik output uses useStore({ name: "Steve" }) and a scoped class name generated by useStylesScoped$. The Angular output declares name = "Steve" as a class property and moves the style into the component's styles array.

Why this matters for design systems

If you maintain a component library that must work across multiple frameworks, writing and testing each version separately multiplies the maintenance cost. Mitosis lets you keep one canonical implementation and regenerate the rest. The trade-off is that you work within Mitosis's supported subset of JSX, so very framework-specific features may not translate cleanly. For shared, presentational components and design-system primitives, that subset is usually enough.

Getting started

The site offers a Get Started path and a Playground where you can paste a Mitosis component and inspect the generated output for each framework. The Playground is the fastest way to verify how a given construct compiles before committing to it in a real project.

Mitosis compiles a single component source file into native code for React, Angular, Vue, Svelte, and Qwik. The homepage explicitly names those five and adds "and many more frameworks," so treat the listed set as confirmed and the rest as likely but unverified until you check the docs.

Confirmed targets

The site's own example shows the same component written once in mitosis.jsx and emitted as framework-specific code:

The example component is deliberately simple — an input bound to a name state value, styled red — which is enough to show that state, event handlers, and scoped CSS all survive the transform.

What the page does not confirm

• The exact full list beyond those five. "Many more frameworks" is not enumerated on the homepage.
• Whether any target is experimental, partially supported, or requires a plugin.
• Version-specific behavior for any framework.

If your stack isn't in the table above, don't assume support — check the official documentation for the current target list before committing to a migration.

How to verify a target yourself

The fastest check is the Playground linked from the homepage:

1. Paste or write a component in Mitosis JSX.
2. Select the output framework.
3. Compare the generated code against what you'd hand-write.

If the output compiles and behaves the same in your target framework, that target is usable for your case regardless of what the marketing copy says.

Practical takeaway

For a multi-framework design system, the confirmed five cover most mainstream choices: React and Vue for web apps, Angular for enterprise codebases, Svelte for compiled-output projects, and Qwik for resumability-focused builds. Anything outside that set needs a documentation check first.