What is SolidJS?
What SolidJS is, how fine-grained reactivity differs from a virtual DOM, and why that distinction matters.
2 min read
SolidJS is a JavaScript library for building user interfaces. It looks a lot like React — JSX, components, props — but the engine underneath is completely different, and that difference is the whole point of learning it.
React re-runs your component function on every state change, builds a new virtual DOM tree, diffs it against the previous one, and patches the real DOM with whatever changed. Solid skips all of that. It compiles your JSX into real DOM-creation code at build time, and wires up fine-grained reactivity so that when a piece of state changes, only the exact DOM node (or attribute, or text) that depends on it updates — nothing re-renders, nothing gets diffed.
No virtual DOM, no re-renders
function Counter() {
const [count, setCount] = createSignal(0);
console.log("Counter setup ran");
return (
<button onClick={() => setCount(count() + 1)}>
Clicks: {count()}
</button>
);
}In React, console.log("Counter setup ran") would print on every click, because the whole function body re-executes as part of re-rendering. In Solid, it prints once. Clicking the button updates only the text node holding count() — the function body that created the button never runs again. There's no component re-render step to trigger.
Signals are the reactive primitive
That update happens because count isn't a plain variable — it's a signal, created with createSignal. A signal is a getter/setter pair that Solid's reactive system can track. When you read a signal (count()) inside JSX, Solid remembers "this DOM node depends on this signal." When you write to it (setCount(...)), Solid updates exactly the things that read it — directly, without asking your component to run again.
You'll spend the next several lessons learning signals, derived values (createMemo), and effects (createEffect) in depth — together they form Solid's entire reactivity model. Everything else in the library (components, control-flow helpers, stores) is built on top of these three primitives.
Why this matters in practice
Fine-grained reactivity isn't just an implementation detail — it changes how you write code:
- You don't need
useMemo/useCallbackto avoid expensive re-renders, because there are no re-renders to avoid. - Components run once, so patterns that assume "this runs again on every update" (common in React) need to be rethought — you'll see this repeatedly, especially with props.
- Performance is often better by default, since Solid updates the DOM directly instead of re-computing and diffing a virtual tree.
The trade-off is a small set of Solid-specific rules — like not destructuring props — that trip up developers coming from React. This course covers those explicitly, because they're the most common source of bugs for people who already know React's mental model and assume Solid works the same way underneath. It doesn't — and that's the reason it's fast.