SolidJS: Compiling JSX to Real DOM Nodes, Not a Virtual One

Compiling JSX to Real DOM Nodes, Not a Virtual One

The README states its core design choice in one sentence: "Instead of using a Virtual DOM, it compiles its templates to real DOM nodes and updates them with fine-grained reactions." The practical consequence follows immediately after: "Declare your state and use it throughout your app, and when a piece of state changes, only the code that depends on it will rerun." The README's own counter example shows the smallest version of that pattern:

import { createSignal } from "solid-js";
import { render } from "solid-js/web";

function Counter() {
  const [count, setCount] = createSignal(0);
  const doubleCount = () => count() * 2;

  return (
    <>
      <button onClick={() => setCount(c => c + 1)}>
        {doubleCount()}
      </button>
    </>
  );
}

render(Counter, document.getElementById("app")!);

createSignal returns a getter and a setter rather than a single mutable variable, and doubleCount is just a plain function wrapping an expression, what the README calls derived state.

Why the Component Function Only Runs Once

The README walks through what its own compiler does to that example, and the result looks nothing like a typical virtual-DOM render function. It imports template, delegateEvents and insert from solid-js/web, and pulls the static button markup out into a single reusable template once, rather than rebuilding it on every state change. The README's own label for this is a "render-once mental model: your components are regular JavaScript functions that run once to set up your view," paired with "automatic dependency tracking: accessing your reactive state subscribes to it."

That combination is why count() has to be called as a function inside JSX rather than read as a plain variable: the call itself is what registers the subscription the fine-grained update later depends on. A `<div>` in the rendered output is a real div the whole time, which the README calls out specifically as making the result "naturally debuggable" with ordinary browser devtools.

Two Starting Points: a Vite Template, or Wiring babel-preset-solid In Yourself

The README's quick start scaffolds a new app with degit rather than a heavier CLI:

npx degit solidjs/templates/js my-app
cd my-app
npm i
npm run dev

Swapping templates/js for templates/ts gives the same flow in TypeScript, and either one, the README says, "will create a minimal, client-rendered application powered by Vite." For an existing setup instead, the README documents adding Solid's JSX support directly:

npm i -D babel-preset-solid
npm i solid-js

with the preset registered in a babel config as "presets": ["solid"], and, for TypeScript specifically, the tsconfig set to jsx: "preserve" with jsxImportSource: "solid-js" so the compiler knows whose JSX runtime to target.

The Repository Itself Only Allows pnpm

The flexibility in the Quick Start, npm, yarn or pnpm, does not extend to Solid's own repository. package.json's preinstall script runs npx only-allow pnpm, which fails immediately if a contributor tries to install with npm or yarn instead. Once dependencies are in, the actual test, build and type-check commands all delegate to Turborepo: test runs turbo run test test-types, build runs turbo run build, and types runs turbo run types, fanning each command out across the packages/ workspace.

Releases follow the Changesets workflow rather than a manual version bump: the bump script runs changeset add, and release:only runs changeset publish, chained after build and types in the full publish script. A postinstall step also runs simple-git-hooks.

Built-In State Management, Instead of a Separate Library

The README's "Powerful" section lists what ships inside the framework rather than as an ecosystem add-on: "Performant state management is built-in with Context and Stores: you don't have to reach for a third party library to manage global state." Resources are described as a way to treat server-loaded data like any other piece of reactive state, paired with Suspense and concurrent rendering to keep the UI responsive while that data loads. The same section states Solid has "full SSR and serverless support, with streaming and progressive hydration."

The performance claims around all of this, "almost indistinguishable from optimized vanilla JavaScript," are backed by links the README provides itself rather than evidence reproduced here: a JS Framework Benchmark entry, a Bundlephobia size page, and a blog post from the library's creator. Anyone weighing those claims should read that benchmark directly rather than take the README's characterization of it on faith.

The Virtual DOM It Explicitly Avoids

Solid's opening pitch is itself a comparison: "Instead of using a Virtual DOM," naming the mechanism most mainstream JSX libraries, React foremost among them, use to decide what changed between renders. A Virtual DOM framework re-runs a component's render function and diffs the result against the previous output to find what to patch; Solid's compiled approach skips that diffing step entirely by wiring each piece of state directly to the DOM nodes that depend on it.

The tradeoff is conceptual rather than purely technical: a developer used to a component re-rendering on every state change has to unlearn that model, since Solid's components, by the README's own description, run their setup code exactly once. Reading state as a function call rather than a plain value is the visible cost of that different mechanism.

MIT, Written by Ryan Carniato, Still Shipping 2.0 as a Candidate

Solid's license is MIT, stated in both the repository's license field and package.json, which also names Ryan Carniato as the package's author directly rather than an organization. The last recorded push to the repository was 2026-11-02, and the three most recent releases, [email protected], @solidjs/[email protected] and @solidjs/[email protected], were all published on 2026-10-29.

The "rc" in each of those tags matters for anyone deciding when to adopt: as of these releases, Solid's 2.0 line has not reached a final, non-candidate tag across any of the packages in the recent releases. A team adopting today is choosing between a release candidate still being iterated on and whatever stable 1.x line preceded it.

Editorial conclusion

A developer who wants JSX components without virtual-DOM diffing, and who is comfortable with signals as the unit of reactive state, is who this README is written for. A team that needs a long-stable 2.0 release line should wait or pin carefully, since the most recent tags, solid-js, @solidjs/diagnostics and @solidjs/html at 2.0.0-rc.20, are all release candidates, not final 2.0 releases. Before starting a new app, check which quick start path applies: the templates assume Vite and let you pick npm, yarn or pnpm, while the repository's own contributor workflow enforces pnpm specifically.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes