What Is Mitosis by 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.