SolidJS's reactivity model, no virtual DOM, fine-grained updates tied directly to signals, has looked appealing on paper for a couple of years. We'd poked at it in internal tools and the occasional prototype, but SolidStart's release this year gave us an actual meta-framework, file-based routing, server-side rendering, server functions, to build a real client project on top of, rather than just a library to experiment with in isolation. The project was a mid-sized internal operations dashboard with a lot of live-updating data, which made it a good stress test for a reactivity model that markets itself on update performance.
Why signals change how you write components
Coming from React and Vue, the biggest adjustment wasn't syntax, it was the mental model. React re-runs whole components on state change and relies on the virtual DOM diff to figure out what actually changed in the browser. Vue's reactivity is proxy-based and mostly implicit, the framework tracks dependencies for you behind the scenes. Solid does neither. A signal read inside JSX creates a direct subscription from that specific DOM node to that specific piece of state, and when the signal updates, only that node updates. There's no component re-render step to reason about at all, because components in Solid only run once, to set up the reactive graph, not on every state change.
- Signals as the core primitive took the team about a week to internalize coming from React and Vue's more implicit reactivity models, but once it clicked, debugging re-renders became noticeably more predictable, there simply isn't a re-render to chase down, only a signal graph to trace.
- Performance on data-heavy dashboard views was excellent, with none of the unnecessary re-render overhead we're used to fighting in React without careful memoization, and none of the `useMemo`/`useCallback` bookkeeping that comes with it.
The catch is that the mental model punishes old habits more than it should. Destructuring props in a Solid component silently breaks reactivity, because you've read the signal's value once at destructure time instead of subscribing to it. We hit this bug three separate times in the first two weeks before the pattern of "keep props as an object, access fields inline in JSX" became muscle memory. It's a sharp edge worth flagging to anyone evaluating Solid for a team coming from hooks-based React.
What SolidStart got right
SolidStart's file-based routing and server functions felt familiar to anyone who's used Next.js or Remix, which lowered the framework-level learning curve considerably, most of the new territory was Solid's reactivity, not SolidStart's routing conventions. Server-side rendering worked out of the box for our dashboard's initial data load, and the resulting time-to-interactive was noticeably faster than the equivalent React version we'd shipped for a similar internal tool a year earlier, largely because there's so much less client-side JavaScript doing setup work on first paint.
- Server functions let us colocate data-fetching logic with the components that use it without a separate API layer, which cut down on boilerplate for a dashboard with a lot of small, page-specific queries.
- Hot module reloading preserved component state reliably during development, a small thing, but one that saved real time across a project with this much iterative UI tweaking.
The ecosystem gap is real
This is the honest tradeoff, and it's the one we'd emphasize most to another team considering Solid for a client project. The component ecosystem is smaller. Several UI libraries and integrations we'd reach for instinctively in React or Vue, rich data tables, certain charting wrappers, a couple of drag-and-drop libraries, simply don't have mature Solid equivalents yet. We ended up building a custom sortable table component from scratch that would have been a dependency install in a React project. That's not necessarily wasted work, our version is smaller and faster than most off-the-shelf table libraries, but it's real time that has to be budgeted honestly in a project estimate.
- Hiring and onboarding is the real cost. Solid knowledge is rare enough that every new team member needs a real ramp-up period, and it's not yet a skill candidates list on resumes the way React or Vue experience is.
- Community resources are growing but still thin compared to React's ecosystem; Stack Overflow answers and blog posts for edge cases are noticeably harder to find, so more debugging happens by reading source than by searching.
What we'd do differently
Looking back, we'd invest more upfront in a small internal style guide covering the destructuring pitfall and a few other reactivity gotchas before the whole team started writing components in parallel. We caught the pattern early, but a written guide would have saved a few redundant lessons. We'd also budget more explicit time in the estimate for building missing ecosystem pieces rather than discovering the gap mid-sprint.
SolidStart delivered on the performance and developer-experience promise for the right kind of project. We wouldn't yet recommend it as a default over React or Vue for a client without in-house Solid expertise or the appetite to build a few things from scratch, but for internal, performance-sensitive tools where the team has room to invest in the learning curve, it's now a real option in our toolkit rather than a bet we'd hesitate to make again.
How the deployment story compares
SolidStart supports multiple deployment targets through adapters, similar in spirit to what SvelteKit and Remix offer, and we tested both a traditional Node server deployment and a serverless target for the dashboard. The serverless adapter worked cleanly for our case, since most of the dashboard's routes were either static or backed by fast, targeted server-function calls rather than long-running requests. Switching adapters mid-project to compare the two took an afternoon rather than a rearchitecture, which was a pleasant surprise given how young the framework still is; a lot of the adapter-swapping pain we'd expected from a newer meta-framework simply didn't materialize.
- Build output for the dashboard was smaller than the equivalent React version by a meaningful margin, largely because Solid's compiler produces highly optimized, minimal-runtime output rather than shipping a general-purpose reconciliation engine that has to stay generic enough to handle every possible component pattern.
- Type inference across server functions, from the server-side data-fetching call through to the client component consuming it, worked end to end without manual type annotations in most cases, which is a smaller thing than the reactivity story but saved real friction day to day.
Testing patterns we had to figure out ourselves
Testing Solid components properly turned out to be one of the less-documented corners of the ecosystem at this point. The testing library ecosystem for Solid exists and is functional, but patterns for testing components that rely heavily on signals and effects aren't as well established as the equivalent React Testing Library conventions the team already had muscle memory for. We ended up writing a handful of internal testing utilities specifically for asserting on signal values after simulated interactions, since the off-the-shelf tooling assumed simpler cases than our dashboard's more stateful components actually needed.
- Snapshot testing needed more care than usual, since a snapshot taken at the wrong point in a signal's update cycle could capture a transient intermediate state rather than the settled value, a category of flaky test we hadn't had to think about with React's more predictable render-commit cycle.
- End-to-end testing with a browser automation tool was unaffected by any of Solid's reactivity quirks, which was a reassuring signal that the framework choice, whatever friction it introduced at the unit level, didn't leak into the parts of the test suite that actually simulate a real user.
Where we landed on the broader question
None of these rough edges were dealbreakers, but they add up to a real cost that a team evaluating Solid for the first time should account for honestly rather than discovering mid-project. The performance and reactivity-model wins are genuine, and for the right project, an internal tool, a performance-critical dashboard, a team with room to invest, they're worth the cost. For a client-facing product on a tight timeline with a team new to the framework, we'd still counsel caution until the ecosystem, particularly around testing and third-party components, catches up further.
Rolling this out to a second project
We've since started a second, smaller SolidStart build specifically to test whether the first project's lessons actually transferred, rather than assuming a single success generalizes. The destructuring pitfall never resurfaced, the written style guide caught it in review on the one occasion a new contributor tripped on it, which validated that specific process fix directly. The ecosystem gap was smaller on the second project too, partly because we now have a small internal library of the components we built from scratch the first time around, a sortable table, a handful of form primitives, which meaningfully lowered the "build it ourselves" tax on the second attempt.