Components run once while signals update DOM expressions
Solid uses JSX, but its execution model differs from React's. A component function normally runs once to create the view. createSignal returns an accessor and setter; reading the accessor inside an expression records a dependency. When the value changes, Solid reruns the dependent expression and updates the associated DOM node. There is no virtual tree diff for the whole component. The result is direct and inspectable, though developers must learn where a reactive read occurs.
The repository we measured was compact before installation: 187 files, about 22,926 source lines, and 1.4 MB checked out. Its packages still cover signals, stores, DOM rendering, server rendering, web storage, hyperscript, tagged templates, and universal renderers. Suspense, portals, error boundaries, streaming SSR, and progressive hydration are in scope. This is a focused UI core, while routing, project scaffolding, and full application conventions live in adjacent Solid tooling.
The 1.4 MB checkout expands to 215 MB after install
Pnpm installed 676 packages and used 215 MB in our sandbox. The repository is a workspace monorepo, so contributors receive compilers, types, test runners, DOM emulation, build tools, and several renderer packages. Application users installing solid-js do not inherit this exact development tree. The distinction matters when judging adoption: our figures describe a source checkout at commit b25c557, not a generated Solid application or the published runtime bundle.
The build took 48 seconds on 3 CPUs with 8 GB of RAM and Node 22. The root package requires pnpm 9.15 and rejects other package managers during repository installation. Two CI workflow files were present, with no Dockerfile and no top-level tests directory. Tests live with the packages rather than in a root tests folder, so that repository signal should be read alongside the successful suite rather than as missing coverage.
What happened when we ran it
Our sandbox installed the workspace in 14 seconds, built it in 48 seconds, and ran Vitest in 36 seconds. All 487 tests passed, with 0 failures. The run took place in a fresh unprivileged Node 22 container against commit b25c557. No install, build, or test problem appeared in the supplied result, which makes this the cleanest possible repository trial.
The 487 passing cases do not establish browser rendering speed or application bundle size. We did not run a UI benchmark, deploy SSR, hydrate a page, or compare Solid with another framework. Performance claims need a representative application, production compiler settings, and the target browsers. What our 98 seconds of install, build, and test work does show is that the current monorepo can be reproduced without hidden services or credentials.
JSX needs a Solid compiler transform
The recommended application path installs solid-js and babel-preset-solid, or uses the Solid Vite integration through a starter. TypeScript must keep JSX for the transform and set jsxImportSource to solid-js. Those settings let the compiler separate static HTML from reactive insertions. Teams using unusual bundlers should prove that development and server export conditions resolve correctly, especially because the v1.9.0 release removed the older browser field to avoid bundler conflicts.
Our 48-second build validates the repository's configured toolchain, not every custom bundler. The render-once model also changes coding habits. A signal value is read by calling its accessor, and reactive tracking depends on where that call happens. Developers coming from React should complete the concepts tutorial and port one stateful form before estimating a migration. Familiar JSX shortens the syntax learning curve, but it does not make component lifecycles equivalent.
Two open select issues matter for dynamic forms
Issue 1754 reports that spreading props onto a select can set its value before child options exist, leaving the value empty in the provided reproduction. Issue 2241 reports a related case where options arrive later and the already-set value is not reflected. Both are narrowly described open reports, not evidence that every Solid form fails. A form-heavy application should include asynchronous options, spread props, reset behavior, and server hydration in its acceptance tests.
The clean 487-test run did not execute either linked browser reproduction in our sandbox. Cross-document rendering has another documented edge: issue 2358 says elements placed into an iframe through Portal are created from the parent window's Node realm. Most sites will never care. Editors, preview tools, and embedded design systems may care a great deal, so those teams should test instanceof, styles, events, and cleanup inside their actual iframe boundary.
Package 1.9.15 is active while 2.0 RC work continues
The current package file identifies solid-js 1.9.15. GitHub's latest formal release is v1.9.0 from September 2024, yet the repository was pushed on September 8, 2026 and had several pull requests updated that day. GitHub showed 35,993 stars and 31 open issues and pull requests. That activity makes the older release page poor evidence of project health; the combined open count is not a count of confirmed bugs.
Solid 2.0 RC work is visible in the current queue, including issue 3274 about an uninitialized derived setter receiving a value inconsistent with its type. Teams that need stable contracts should remain on a pinned 1.9.x package until the 2.0 behavior and migration guidance settle. For a new interface, the 14-second install and 487 passing tests make evaluation cheap. The decision turns on whether the team prefers explicit signal accessors and direct DOM updates enough to retrain its JSX instincts.