Why SolidJS Ditches the Virtual DOM for Fine-Grained Reactivity

The Problem: VDOM Diffing Becomes a Bottleneck

When you're building a real-time dashboard that updates dozens of metrics every second, the Virtual DOM (VDOM) reconciliation process can consume a surprising amount of CPU time. React's diffing algorithm walks the entire component tree, creates new fiber nodes, and compares them against the previous render—even if only a single text node changed. That overhead adds up, especially on mobile devices or in long-running applications where garbage collection pauses become noticeable.

SolidJS takes a different approach: it skips the VDOM entirely. Instead of re-running component functions, it tracks exactly which DOM nodes depend on which pieces of state. When a signal changes, only the associated effect runs, updating the specific text node or attribute. The component function executes once during initialization and never again.

How Fine-Grained Reactivity Works

Solid's reactivity is built on createSignal and createEffect primitives. A signal holds a value and notifies subscribers when it changes. An effect runs a function and automatically records every signal read during that execution. Later, when any of those signals update, the effect re-runs—but only that effect.

This is implemented with Proxies (or getters/setters in older environments) that intercept property access. The runtime maintains a dependency graph: signal → effect → DOM node. No tree diffing, no fiber reconciliation, no synthetic event system. The browser's native event listeners attach directly to the real DOM elements.

Worked Example: A Live Counter Without Re-renders

Consider a simple counter component. In React, the function re-runs on every setCount. In Solid, the component body runs once, creating a signal and an effect that updates a single text node.

import { createSignal, createEffect } from 'solid-js';

function Counter() {
  const [count, setCount] = createSignal(0);
  
  createEffect(() => {
    document.getElementById('counter').textContent = count();
  });
  
  return (
    <button onClick={() => setCount(c => c + 1)} id="counter">
      0
    </button>
  );
}

Place a console.log inside the component body. Click the button five times. The log appears once. Open DevTools → Performance, record a click, and you'll see only a textContent setter on the button element—no subtree modifications, no component function re-entry.

Trade-offs and Gotchas

The mental model shift is the biggest hurdle. Developers used to React's re-execution model often try to destructure props: const { title } = props;. That breaks reactivity because destructuring reads the proxy once at initialization, losing the subscription. Always access props as props.title inside effects or JSX expressions.

Memory management is automatic for effects created within the component scope—they're disposed when the component unmounts. However, manual subscriptions (e.g., window.addEventListener inside onMount) require explicit cleanup in onCleanup, or they'll leak in long-lived apps.

Library compatibility is another consideration. Components that assume VDOM reconciliation (some animation libraries, complex table components) may need wrappers like @solidjs/meta or custom directives to work with Solid's direct DOM manipulation.

When to Choose SolidJS

Pick Solid when you have high-frequency updates, large lists with fine-grained changes, or strict performance budgets. The bundle size is small (~7 KB gzipped), and the learning curve is shallow if you respect the "no destructuring" rule. Verify the behavior yourself: add a log in the component body, watch the Performance tab, and confirm only the expected DOM nodes mutate. That's the signal you're getting fine-grained updates without the VDOM tax.