Solid.js

Solid.js is a JavaScript library for building user interfaces that takes a fundamentally different approach from Virtual DOM frameworks like React. Components run once as plain functions to set up the view, and JSX templates are compiled at build time into real DOM node creation code. Reactive primitives such as createSignal, createMemo, and createEffect then take over: when a piece of state changes, only the specific DOM expressions that read it re-run, with no diffing or re-rendering of components involved.

This gives Solid performance close to hand-written vanilla JavaScript on benchmarks like the JS Framework Benchmark, while still offering the modern feature set developers expect: Context, Suspense, streaming SSR, progressive hydration, Error Boundaries, and concurrent rendering are all built in rather than bolted on. Built-in Stores provide nested reactive state without a separate state-management library, and the library ships isomorphic — the same components render on client and server.

The project is maintained by a small, highly active core team (Ryan Carniato and collaborators) with a fast release cadence and a growing ecosystem of community primitives, component libraries, and meta-frameworks (SolidStart) built on top of it.

What You Get

• Fine-grained reactive primitives — createSignal, createMemo, createEffect, createResource — that track dependencies automatically and update only what changed
• A compiler-driven JSX runtime that turns templates into real DOM node creation code instead of diffing a virtual DOM tree
• Built-in Stores (createStore) for nested, proxy-based reactive state without needing a third-party state library
• Full SSR support with streaming and progressive/selective hydration via solid-js/web and the server renderer
• Suspense, concurrent rendering, Error Boundaries, Context, and Portals as first-class primitives rather than add-ons
• A universal renderer API for building custom renderers (used by solid-native, etc.) beyond the DOM

Common Use Cases

• Building performance-sensitive client-rendered SPAs where re-render cost matters (dashboards, editors, data-dense UIs)
• Server-rendered apps needing streaming SSR and progressive hydration to reach interactivity faster
• Teams wanting React-like JSX ergonomics without adopting a virtual DOM or memoization boilerplate (useMemo/useCallback)
• Projects that want built-in global/nested state management (Stores) instead of pulling in Redux/Zustand/Jotai
• Building custom renderers for non-DOM targets (native, canvas, etc.) on top of Solid’s universal reactive core

Under The Hood

Architecture The reactive core (src/reactive: signal.ts, scheduler.ts, observable.ts, array.ts) is decoupled from the DOM render layer (src/render: component.ts, flow.ts, hydration.ts, Suspense.ts, index.ts), with a separate server entry (src/server) and web-specific DOM bindings (web/src: core.ts, client.ts, server-mock.ts). An Owner/Computation ownership tree in signal.ts underlies createRoot, createEffect, and cleanup semantics — every computation is scoped to an Owner that tracks its own dependencies and its child computations, so disposing a root recursively tears down its subtree. The Store package layers Proxy-based nested reactivity on top of the same signal primitives rather than reimplementing tracking from scratch. This split means changing scheduling logic in signal.ts ripples through effects, Suspense timing, and hydration order, while the DOM-specific “insert”/“template” codegen in the render layer can be swapped for another target without touching the reactive core, as solid-js/universal already demonstrates.

Tech Stack TypeScript throughout, built as a pnpm workspace orchestrated by Turborepo across five packages (solid, solid-element, solid-ssr, babel-preset-solid, test-integration). The core bundles via Rollup using @rollup/plugin-babel with @babel/preset-typescript, node-resolve for module resolution, and a custom babel plugin that aliases an internal rxcore import to the DOM-specific core module at build time — letting the same signal/effect code back both DOM and server renderer builds. JSX authoring is handled by the separate babel-preset-solid package, which compiles JSX into dom-expressions template/insert calls rather than React.createElement; Vite integration is provided via vite-plugin-solid. The published package ships with no runtime framework dependencies — dom-expressions is a devDependency used only by the compiler toolchain.

Code Quality Tests run on Vitest, with jsdom for DOM-environment specs and a dedicated node-environment config for SSR-path tests, plus explicit type-test files that assert TypeScript type inference itself rather than only runtime behavior — a notably rigorous bar for a UI library. CI runs full builds, the test suite, and coverage reporting on every pull request. Naming follows a consistent create* factory convention across the public API, error boundaries and cleanup are explicit first-class primitives rather than implicit try/catch, and Prettier plus pre-commit hooks enforce formatting.

API Design Solid’s core bet — auto-tracked fine-grained signals compiled directly into real DOM mutation code, with no virtual DOM or component re-render step — occupies a genuinely distinct point in the UI-library design space, closer in spirit to proxy-based reactive systems but pushed through a compiler rather than left as a pure runtime layer. The API stays close to plain JavaScript functions and closures (a component is just a function called once), keeping the surface simple while still supporting custom renderers, external reactive sources, and concurrent rendering usually reserved for much heavier frameworks. Getting started requires minimal boilerplate — one Babel preset plus a couple of imports — though the “no re-renders, only fine-grained updates” mental model is a genuine conceptual departure for developers coming from React and takes some relearning.