SolidJS looks like React at a glance — JSX, components, hooks-like functions — but the underlying execution model is fundamentally different: components run once, not on every state change, and reactivity updates the DOM directly without re-running your component function at all.
SolidJS is a UI library using fine-grained reactivity instead of a virtual DOM — signals track exactly which pieces of the DOM depend on which pieces of state, and updates apply directly to those specific DOM nodes when state changes, without re-executing the component function or diffing a virtual tree. This produces notably strong runtime performance characteristics compared to re-render-based frameworks.
Why SolidJS Matters (and When to Skip It)
Because component functions run once (not on every state update) and updates are surgical, SolidJS avoids a whole category of performance concerns that React developers spend real effort managing — unnecessary re-renders, memoization (useMemo/useCallback), and re-render cascades simply don't apply in the same way, since there's no re-render step for state changes to trigger.
Skip SolidJS if your team is deeply invested in React's ecosystem, hiring pool, or existing patterns — Solid's JSX-like syntax makes it approachable, but the underlying execution model is different enough that "it looks like React" can create false expectations if the mental model isn't actually understood.
Getting Started with SolidJS
npx degit solidjs/templates/ts my-app
cd my-app
npm install
npm run dev
A basic component with a signal:
import { createSignal } from "solid-js";
function Counter() {
const [count, setCount] = createSignal(0);
return (
<button onClick={() => setCount(count() + 1)}>
Count: {count()}
</button>
);
}
Core SolidJS Concepts Every Developer Should Know
Signals are called as functions, not accessed as values. count() reads the signal's current value — this function-call syntax is what enables SolidJS's fine-grained reactivity tracking, since the framework can detect exactly where a signal is read and wire up precise DOM updates to that specific location.
Components run once, not on every update. Unlike React where the component function re-executes on every state change, a Solid component's function body runs a single time to set up the reactive bindings — this is the core mental model shift, and treating Solid components like React components (expecting re-execution) leads to real bugs.
function Component() {
console.log("this runs once, not on every count change");
const [count, setCount] = createSignal(0);
return <div>{count()}</div>;
}
createEffect runs reactively based on signals it reads, similar conceptually to useEffect but tracking dependencies automatically rather than requiring an explicit dependency array:
createEffect(() => {
console.log(`count is now ${count()}`);
});
No virtual DOM means no reconciliation/diffing step. Updates apply directly to the specific DOM nodes affected by a signal change, which is both why Solid tends to benchmark very well and why understanding fine-grained reactivity (rather than the virtual-DOM mental model) matters for writing idiomatic Solid code.
Common SolidJS Mistakes and How to Fix Them
Mistake 1: destructuring props, which breaks reactivity. Since components run once, destructuring a prop captures its value at that single execution moment rather than tracking future changes. Fix: access props via props.value directly (not destructured) wherever the value needs to stay reactive.
// breaks reactivity
function Component({ value }) { return <div>{value}</div>; }
// correct
function Component(props) { return <div>{props.value}</div>; }
Mistake 2: applying React mental models directly (expecting re-renders, using signals like React state without understanding the function-call read pattern). Fix: learn Solid's actual execution model rather than assuming React patterns translate directly.
Mistake 3: forgetting to call signals as functions, using count instead of count() and getting the signal accessor itself rather than its value. Fix: always call signal accessors as functions when reading their value.
When Should You Use SolidJS Instead of React?
Use SolidJS when runtime performance is a priority and your team is willing to learn its distinct fine-grained reactivity model rather than assuming React familiarity transfers directly. Use React when you need its much larger ecosystem, hiring pool, and community resources, which remain substantially larger than Solid's despite Solid's strong technical characteristics.
SolidJS in Production
Invest time in actually understanding fine-grained reactivity rather than treating Solid as "React with different syntax" — the mental model difference is where real bugs come from if skipped. Also avoid destructuring props reflexively out of habit from other frameworks, since it's one of the most common correctness mistakes for developers new to Solid specifically.
If runtime performance is a measured, real bottleneck in a React application and your team has bandwidth to learn a genuinely different reactivity model, SolidJS is worth evaluating — though the ecosystem tradeoff against React should be weighed honestly.