SolidJS: a compiled, fine-grained reactive UI library

The problem Solid targets: rerender cost in virtual-DOM frameworks

Most component frameworks rebuild a description of the UI and diff it against the previous description. Solid's README states the library takes the other route: it compiles templates to real DOM nodes and updates them with fine-grained reactions, so when a piece of state changes only the code that depends on it reruns. The intended audience is JavaScript and TypeScript developers building interactive interfaces who have used JSX before and want the component function to execute once rather than on every state change. The README makes that model explicit with a console.log inside the component body and the comment "The body of the function runs once...". That single sentence is the clearest statement of who this is for: developers who find repeated component execution hard to reason about, and who would rather subscribe to individual values than memoize their way out of unnecessary work.

How the compiler turns JSX into direct DOM updates

The mechanism is a Babel transform. The README shows the same counter example compiled, and the output imports template, delegateEvents and insert from solid-js/web. Static markup is hoisted into a single template call: the compiled sample contains a line that reads template(`<button>Increment: `). The component then returns an immediately invoked function whose result is a real DOM node, and the README annotates that node with the comment "_el$ is a real DOM node!". Signals are the runtime half of the pair. createSignal returns an accessor and a setter, and derived values are plain functions that call the accessor, as in the README's doubleCount example. Dependency tracking is automatic because reading a signal during a computation subscribes that computation to it. Nothing in the README describes a scheduler that batches arbitrary component subtrees, so the update granularity is the expression that read the signal. The README also points to a playground link for the counter, which is the fastest way to see the compiled output without setting up a build.

Installing SolidJS and running a first counter

The README gives two paths. The fastest is the degit template, which produces a minimal client-rendered app powered by Vite. For JavaScript:

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

For TypeScript, the README substitutes the ts template:

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

The README notes that npm, yarn and pnpm all work for the install and dev commands. The second path is adding Solid to an existing setup. The README recommends JSX and gives these two install commands:

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

You then add the preset to your Babel configuration. The README shows the entry as it appears in a .babelrc, webpack Babel config or Rollup configuration:

"presets": ["solid"]

For TypeScript, the README says to set your tsconfig to handle Solid's JSX, with jsx set to preserve and jsxImportSource set to solid-js. If you skip that step, the compiler will not resolve Solid's JSX types. Once the build runs, the counter from the README's At a Glance section is the smallest useful program: createSignal(0), a doubleCount function that multiplies the accessor by two, and render(Counter, document.getElementById("app")!) from solid-js/web. The console.log in the component body should print once, no matter how many times you click the button.

Where the render-once model changes how you write components

Because the body runs once, anything you would normally recompute on each render has to become a function or a reactive primitive. The README's doubleCount is exactly that: an arrow function wrapping count() * 2 rather than a variable holding a number. Destructuring props, a common habit from other JSX frameworks, does not fit this model, and the README does not present a workaround because the model itself is the answer: keep reading the value at the point of use. The same constraint applies to conditional rendering and list rendering, where the framework needs a function or a reactive source to know what to re-evaluate. This is the main conceptual cost of adopting Solid. The payoff is that a div in your component is a real div, which the README calls "naturally debuggable": browser devtools inspect the actual element tree rather than a component tree that has to be mapped back to DOM.

The 2.0 release candidate is the current published line

This is the part a reader should check before starting. The most recent releases listed for the repository are [email protected], @solidjs/[email protected] and @solidjs/[email protected], all published on 2026-08-28. The last push to the repository was on the same date. The README's install instructions, however, describe the 1.x setup: babel-preset-solid, the "solid" preset, and the tsconfig entries. Nothing in the README explains how to opt into the 2.0 release candidates, and the README does not document a migration path from 1.x to 2.0. Treat that gap as the first thing to resolve. If you are starting a project today, confirm which major version the documentation you follow corresponds to, and pin accordingly, because an rc tag is not a stable release and the package names in the 2.0 line differ from solid-js alone.

Solid compared with React on update strategy

React is the obvious alternative for a JSX-based component library, and the difference is architectural rather than stylistic. React re-executes component functions and reconciles a virtual tree; Solid executes the component function once and wires up subscriptions to the signals that function read. That is why the README can put a console.log in a component body and promise it runs once, and why the compiled output contains a hoisted template string instead of a createElement-style call. The practical trade-offs follow from that. Solid's ecosystem is smaller, so a library you depend on may not have a Solid binding. React's model tolerates a wider range of component code, including patterns that recompute derived values on every render, while Solid asks you to express derived state as functions. If your team already knows React deeply and the application is not render-bound, the migration cost is real and the benefit is mostly in update granularity, not in features: the README lists JSX, fragments, Context, Portals, Suspense, streaming SSR, progressive hydration, Error Boundaries and concurrent rendering as available in Solid too.

Licence, repository layout and upgrade cost

Solid is MIT licensed, stated in the repository's package.json and in the LICENSE file at the top level. MIT is permissive and places few conditions on commercial use; this is a description of the licence identifier, not legal advice, and you should read the LICENSE file yourself. The repository is a pnpm workspace: package.json sets private to true, the preinstall script runs npx only-allow pnpm, and pnpm-workspace.yaml plus turbo.json drive the build across the packages/ directory. Releases are managed with Changesets, visible in the .changeset directory and the bump and release:only scripts. For consumers this matters in one way: the published artifacts come from a monorepo that splits functionality across packages such as solid-js, @solidjs/web and @solidjs/universal, so a 2.0 upgrade may involve more than one dependency line. The repository is not archived, and the last push was on 2026-08-28, which is when the 2.0.0-rc.4 packages were published.

Editorial conclusion

Adopt Solid if you want JSX with a render-once component model and are willing to configure Babel and TypeScript yourself, or to start from the degit template. Do not adopt it if you need a stable 1.x line for a long-lived product right now: the newest published packages are 2.0.0-rc.4, and the README's install instructions still describe the 1.x setup. Before committing, verify that the 2.0 release candidates match the documentation you plan to follow, and check that your bundler setup can run babel-preset-solid.

Frequently asked questions

Official sources

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