The state of Solid.js in 2026: signals, performance, and growing influence

A framework that punches way above its weight

If you’ve been following the JavaScript ecosystem over the past few years, you’ve probably noticed something interesting: signals are everywhere now. Angular has them. Vue’s reactivity system is built on similar principles. Even React has been forced to respond with its own approach. And at the center of this paradigm shift sits Solid.js — a framework that has been championing fine-grained reactivity for over a decade.

With Solid 2.0 in active experimental development, SolidStart 2.0 already in alpha, and its ideas being adopted by frameworks orders of magnitude larger, it’s the perfect time to take stock of where Solid.js stands in 2026.

Where Solid.js is right now

The current release landscape

Solid.js sits at v1.9.11 as its latest stable release. But the real story is what’s happening behind the scenes — the 2.0.0-experimental branch has been under active development since February 2025, with the @solidjs/signals package being built as the new reactive foundation.

On the meta-framework side, SolidStart has reached 2.0.0-alpha.2 (released February 2026), signaling that the ecosystem is moving in lockstep toward the next major version. One notable architectural shift: SolidStart plans to replace Vinxi with a pure Vite-based system internally called “DeVinxi”.

What Solid 1.9 brought to the table

The latest stable release wasn’t just a maintenance bump. It introduced:

Build-time JSX validation using JSDOM to catch invalid HTML before it hits the browser
Custom element improvements — better shadow DOM event handling, a new bool: attribute namespace, and support for elements with the is attribute
Event handler syntax supporting the handleEvent object pattern for non-delegated events
Server environment fixes where server builds now export client methods (throwing if misused) to prevent build errors

Why Solid.js is fast — and stays fast

If you’ve ever wondered why Solid consistently tops performance benchmarks, the answer lies in its fundamental architecture. While React, Vue, and Angular all use some form of virtual DOM or intermediate representation, Solid takes a radically different approach: it compiles JSX templates into real DOM operations and builds a reactive graph that updates only the precise nodes that change.

There’s no diffing. There’s no reconciliation. When a signal changes, the exact DOM text node or attribute that depends on it gets updated — nothing more.

Here’s what a basic counter looks like in Solid:

import { createSignal } from "solid-js";

function Counter() {
  const [count, setCount] = createSignal(0);

  return (
    <button onClick={() => setCount(count() + 1)}>
      Clicks: {count()}
    </button>
  );
}

It looks like React, but the execution model is fundamentally different. This component function runs exactly once. The JSX compiles to real DOM creation calls, and count() sets up a subscription so that only the text node showing the number re-renders when the button is clicked. The entire component doesn’t re-execute.

Compare that to React where the entire function re-runs on every state change, and you can see why Solid achieves near-vanilla-JavaScript performance in benchmarks.

The benchmark numbers

In the krausest/js-framework-benchmark (7,400+ stars), Solid.js (v1.9.3) consistently competes at near-vanilla-JS performance levels. The benchmark runs on a MacBook Pro M4 with Puppeteer, measuring row creation, updates, selection, swapping, deletion, memory, and bundle size. Solid regularly lands in the top tier alongside vanilla JavaScript implementations — consistently outperforming React, Vue, Angular, and often matching or beating Svelte in key metrics.

What’s particularly impressive is the bundle size story. Solid’s core is remarkably small — roughly 7.6KB minified+gzipped (npm package) — compared to React + ReactDOM at ~45KB, Vue at ~38KB, and Angular at ~85KB+.

In real-world production, companies like Radware have reported Solid bundle sizes of ~80KB compared to React’s ~290KB for equivalent features. Jolt AI uses Solid across 6 platforms (web, VS Code, JetBrains, macOS, Windows, Linux) with 93% code reuse while maintaining low memory footprint for embedded IDE environments.

The signals revolution — and Solid’s role in it

Here’s what makes Solid’s story truly remarkable in 2026: the core concept it pioneered — signals — has become the dominant reactivity paradigm across the JavaScript ecosystem. Let me break down how each major framework has responded.

Angular: Full adoption

Angular’s embrace of signals has been one of the most dramatic framework evolutions in recent memory. Introduced as a developer preview in Angular v16 (May 2023), stabilized in v17, and fully production-ready in v19/v20 (2024–2025), Angular’s signal API mirrors Solid’s model almost directly:

// Angular signals — heavily inspired by Solid's model
import { signal, computed, effect } from '@angular/core';

const count = signal(0);
const doubled = computed(() => count() * 2);

effect(() => {
  console.log(`Count is ${count()}, doubled is ${doubled()}`);
});

count.set(5);

Compare that with Solid’s equivalent:

import { createSignal, createMemo, createEffect } from "solid-js";

const [count, setCount] = createSignal(0);
const doubled = createMemo(() => count() * 2);

createEffect(() => {
  console.log(`Count is ${count()}, doubled is ${doubled()}`);
});

setCount(5);

The resemblance is hard to miss. Angular explicitly positions signals as the foundation of its future reactivity system, gradually replacing RxJS for many use cases. The core primitives — signal(), computed(), and effect() — are a direct reflection of the model Solid.js has been refining for over a decade.

React: The compiler response

React took a different route. Rather than adopting signals directly, the React team released React Compiler v1.0 (October 7, 2025) — a build-time tool that automatically applies useMemo, useCallback, and React.memo() without manual intervention.

This is React’s answer to the problem that signals solve architecturally. In React, components re-render from top to bottom on every state change, and developers have historically needed to manually memoize to prevent unnecessary work. The compiler automates this away — but it’s worth noting that this approach exists largely because of the competitive pressure signals created.

The community has also spoken through projects like use-react-signals and Preact Signals, showing genuine developer demand for Solid-like reactivity within the React ecosystem.

Two philosophies now compete in the frontend world: React’s compiler-driven optimization vs. signals-based fine-grained reactivity (Solid, Angular, Vue, Qwik). Time will tell which approach wins, but signals have clearly shaped the conversation.

Vue: Shared philosophy

Vue 3’s reactivity system — built on ref() and reactive() with Proxy-based tracking — shares deep philosophical similarities with Solid’s signals. Both frameworks use explicit reactive primitives and automatic dependency tracking.

// Vue's reactive primitives
import { ref, computed, watchEffect } from 'vue';

const count = ref(0);
const doubled = computed(() => count.value * 2);

watchEffect(() => {
  console.log(`Count is ${count.value}, doubled is ${doubled.value}`);
});

count.value = 5;

The key difference remains architectural: Vue still uses a virtual DOM for rendering, while Solid renders templates once and builds a reactive graph that handles subsequent updates. But the reactive model underneath is strikingly similar.

TC39: Signals as a language standard

Perhaps the strongest validation of Solid’s approach is the TC39 proposal to add signals to JavaScript as a language standard. It reached Stage 1 in April 2024, with design input from the authors and maintainers of Angular, Solid, Vue, Svelte, Preact, Qwik, MobX, and others. The proposal defines two core types — Signal.State (writable) and Signal.Computed (read-only derived) — and a spec-compliant polyfill is already available for experimentation.

When the programming concept your framework pioneered is being considered for inclusion in the language itself, that’s a level of influence few frameworks ever achieve.

What’s coming in Solid 2.0

The Solid 2.0 roadmap (detailed in GitHub Discussion #2425) is ambitious. Here’s what’s planned:

Pull-based run-once SSR — a new server-side rendering architecture
Concurrent transitions — enabling smoother UI updates during async operations
Self-healing error boundaries — more resilient error recovery
Immutable diffable stores — improved state management primitives
Automatic batching — signal updates grouped for optimal performance
Lazy memos and derived signals — more efficient computed values
createAsync as the standard async primitive — currently available from @solidjs/router, it will become the recommended approach for async data fetching in Solid 2.0

Here’s what createAsync looks like today, paired with the query function for caching and deduplication:

import { query, createAsync } from "@solidjs/router";

const getUser = query(async (id) => {
  const res = await fetch(`/api/users/${id}`);
  return res.json();
}, "user");

function UserProfile(props) {
  const user = createAsync(() => getUser(props.id));

  return (
    <div>
      <h1>{user()?.name}</h1>
      <p>{user()?.email}</p>
    </div>
  );
}

The development is following a phased approach: Experimental (current) → Alpha (formal RFCs, core projects tested) → Beta (ecosystem libraries test new features) → RC. No specific dates have been announced — Ryan Carniato has stated the timeline depends on community feedback and contributions.

Community and adoption

35,200+ GitHub stars on the main repository
~1.49 million weekly npm downloads
Active community on Discord with growing contributor base
SolidHack hackathons ($12,000 in prizes in 2022, $20,000+ in 2024)
31 public repositories under the SolidJS organization

The ecosystem is maturing rapidly. Multiple UI component libraries now support Solid:

Ark UI — 45+ headless, accessible components (supports Solid, React, Vue, Svelte)
Solid UI — a port of shadcn/ui to Solid.js (1,300+ stars)
Kobalte — UI toolkit for accessible web apps and design systems (1,700+ stars)
Corvu — unstyled, accessible UI primitives

Solid is identified as being “favored by small companies” in the State of JS data, which makes sense — smaller teams that can choose their stack freely tend to gravitate toward performance-first solutions.

Ryan Carniato and the 10-year story

One thing that sets Solid apart is the longevity and dedication behind it. Ryan Carniato, currently a Principal Engineer for Open Source at Netlify, has been developing Solid’s reactive model for over a decade. His retrospective “A Decade of SolidJS” traces the framework’s evolution from a personal experiment to an industry-influencing project.

That kind of sustained focus is rare in the JavaScript world, where frameworks rise and fall with alarming regularity. It also means Solid’s reactive model is deeply thought-through — it’s not a trend-chasing API, it’s a philosophy refined over years of real-world application.

Should you use Solid.js in 2026?

This is the question developers always want answered, so let me give my honest take:

Choose Solid if:

Performance is a genuine priority for your application (real-time dashboards, visualization-heavy apps, embedded environments)
You want a React-like developer experience without the virtual DOM overhead
You’re building a new project and your team is open to learning a smaller ecosystem
Bundle size matters — Solid’s ~7.6KB gzipped core is hard to beat

Think twice if:

You need the largest possible ecosystem of third-party libraries and hiring pool
Your team is deeply invested in React patterns and mental models
You need enterprise-grade support and long-term corporate backing guarantees

The honest reality is that Solid.js remains a niche framework by adoption numbers, but it’s an enormously influential one. Using Solid today means betting on a framework whose core ideas have already been validated by the rest of the ecosystem — that’s a strong signal (pun intended).

In my own experience building IoT applications, Solid.js excelled thanks to its minimal footprint and exceptional performance — making it an ideal choice when resource efficiency truly mattered.

Conclusion

Solid.js in 2026 occupies a fascinating position in the JavaScript landscape. It’s not the most popular framework, but it might be the most influential one of the past five years. The signals paradigm it championed is now the foundation of Angular’s reactivity, the philosophical basis of Vue’s system, the competitive pressure behind React’s compiler, and a candidate for inclusion in the JavaScript language itself through TC39.

With Solid 2.0 on the horizon promising concurrent transitions, pull-based SSR, and self-healing error boundaries, the framework continues to push the boundaries of what’s possible in frontend performance. Whether you adopt Solid directly or simply benefit from its influence on your framework of choice, its impact on modern web development is undeniable.

The frameworks may compete, but the ideas transcend them. And right now, Solid’s ideas are winning.