English for SolidJS

SolidJS looks like React at a glance — JSX, components, hooks-shaped functions — but its underlying model is fundamentally different, and conflating the two is the most common source of confusion when a team picks it up.

Key Vocabulary

Fine-grained reactivity — Solid’s update model where only the specific DOM nodes depending on a changed value update, rather than re-running an entire component function, which is the central difference from React’s render model. “This isn’t re-rendering the whole component the way React would — Solid’s fine-grained reactivity means only the text node bound to this signal updates, the rest of the component function doesn’t run again at all.”

Signal — Solid’s core reactive primitive, a getter/setter pair created with createSignal, that automatically tracks where it’s read and updates only those specific consumers when its value changes. “We’re using a signal here instead of component state — calling the setter updates the signal’s value, and Solid automatically knows exactly which parts of the DOM read that signal and updates only those.”

Component runs once — the fact that a Solid component function executes a single time to set up reactive bindings, unlike React where the function re-runs on every state change, which changes how you should think about code inside the function body. “Remember, in Solid the component runs once — that console.log at the top of the function only fires on initial setup, not on every update, because updates happen through signals, not through re-running the function.”

createEffect — Solid’s primitive for running side effects that automatically re-run when the signals they read change, conceptually similar to React’s useEffect but driven by fine-grained dependency tracking rather than a dependency array. “We don’t need to list dependencies manually like a React useEffect array — createEffect in Solid automatically tracks which signals it reads and re-runs whenever any of them change.”

No virtual DOM — like Svelte, Solid compiles JSX into direct DOM-update instructions rather than diffing a virtual DOM tree, meaning updates go straight to the specific DOM nodes that need to change. “Solid has no virtual DOM to diff — the compiler already generates code that updates the exact DOM node tied to a signal, so there’s no reconciliation pass happening on every update.”

Common Phrases

• “Is this fine-grained reactivity, or are we thinking in React’s re-render model by mistake?”
• “Should this be a signal, or does it not need to be reactive at all?”
• “Remember the component only runs once — is this code meant to run on every update or just on setup?”
• “Does createEffect need to depend on this value, or is that an unintended extra re-run?”
• “Are we relying on a virtual DOM diff here that Solid doesn’t actually have?”

Example Sentences

Correcting a common misconception: “This bug is a classic React habit carried over — you destructured the signal’s value at the top of the function expecting it to update on every render, but the component runs once in Solid, so that value is frozen at setup time. You need to call the signal as a function to read it reactively.”

Explaining Solid’s performance model: “The reason this list update is so fast is fine-grained reactivity — Solid isn’t re-running the whole component or diffing a virtual DOM, it’s updating exactly the one list item whose signal changed, nothing else in the tree re-executes.”

Describing an effect dependency issue: “createEffect is re-running more often than we want because it’s reading a signal inside a conditional branch — Solid’s automatic dependency tracking only sees what’s actually read during execution, so restructure the condition if you want to control what it tracks.”

Professional Tips

• Explicitly unlearn React’s re-render mental model when discussing fine-grained reactivity — assuming a component re-runs like React does causes almost all beginner Solid bugs.
• Always call a signal as a function, like count(), to read its current value reactively — destructuring or storing the value directly captures a stale snapshot.
• Remind teammates the component runs once whenever debugging behavior that looks like “state isn’t updating” — it usually means code was written assuming re-execution that never happens.
• Use createEffect for reactive side effects, but be aware its dependencies are inferred from what it reads, not declared explicitly — restructure code if tracking too much or too little.
• Cite no virtual DOM when explaining Solid’s performance characteristics — the update mechanism is categorically different from React’s, not just a faster version of the same thing.

Practice Exercise

1. Explain why Solid components running only once changes how you should write code inside them.
2. Describe how signals differ from calling useState in React.
3. Write a sentence explaining fine-grained reactivity to someone coming from a React background.