Dein Client's Analytics-Dashboard friert für 340 Millisekunden ein, jedes Mal wenn ein Benutzer den Datumsbereich auf einem Chart mit 3.000 Datenpunkten umschaltet. Reacts Reconciler kämpft sich durch VDOM-Knoten, Hooks werden in Kaskaden ausgelöst, und dein Bundle hat gerade 180 kB gzip überschritten. Im letzten Quartal haben wir genau dieses Production-Dashboard – Authentifizierung, Real-Time-WebSocket-Updates, komplexe mehrstufige Formulare, Charting-Modul – in beiden SolidJS und React umgebaut, jeden Render instrumentiert, jeden Bundle-Byte geloggt und die gleichen Benutzerflüsse durch beide Versionen geleitet. Der Performance-Gap war größer als erwartet, aber nicht da, wo man denken könnte.

Die Ergebnisse überraschten uns. Nicht weil ein Framework "gewonnen" hat – sondern weil die Tradeoffs viel nuancierter waren als der Twitter-Diskurs suggeriert. Manche Dinge waren zu erwarten. Manche Dinge überraschten uns völlig. Das ist, was wir wirklich gelernt haben.

Inhaltsverzeichnis

Wir haben die gleiche App in SolidJS und React gebaut: Signals vs Hooks

Die App, die wir gebaut haben

Die Anwendung ist ein Real-Time-Analytics-Dashboard für einen E-Commerce-Client. Hier ist, was es umfasst:

  • Authentifizierungsfluss mit JWT-Tokens und Refresh-Logik
  • Dashboard mit 6 Widget-Panels, jedes zieht Daten von verschiedenen API-Endpoints
  • Real-Time-Order-Feed mit WebSocket-Verbindungen
  • Interaktive Charts mit 5.000+ Datenpunkten (mit einer Charting-Bibliothek)
  • Komplexe Filter-Formulare mit abhängigen Dropdowns und Datumsbereiche-Pickern
  • Admin-Einstellungsbereich mit verschachtelter Zustandsverwaltung
  • Responsive Layout mit Sidebar-Navigation

Beiden Versionen verbinden sich mit der gleichen Backend-API. Beide verwenden TypeScript. Beide verwenden Vite als Build-Tool. Wir hielten Third-Party-Dependencies so ähnlich wie möglich – gleiche Charting-Bibliothek (Chart.js), gleicher HTTP-Client (ky), gleicher WebSocket-Wrapper.

Die React-Version verwendet React 19 mit Hooks. Die SolidJS-Version verwendet Solid 1.9. Wir haben keine Meta-Frameworks verwendet (kein Next.js, kein SolidStart), weil wir die Framework-Unterschiede isolieren wollten, ohne dass Routing und SSR den Vergleich beeinflussen.

Signals vs Hooks: Ein Mental Model Shift

Das ist das Große. Und ehrlich gesagt, brauchte unser Team etwa eine Woche, um nicht mehr React-förmigen Code in SolidJS zu schreiben.

Wie React Hooks funktionieren

Du kennst das, aber es lohnt sich, es für den Vergleich explizit zu formulieren. Reacts Modell ist: Wenn sich der State ändert, wird die Component-Funktion erneut ausgeführt. Die ganze Funktion. Jeder useState, jeder useMemo, jeder useCallback – sie alle sind Mechanismen, um herum um die Tatsache zu arbeiten, dass die ganze Funktion neu läuft.

// React: Diese ganze Funktion wird bei jeder State-Änderung neu ausgeführt
function OrderFeed() {
  const [orders, setOrders] = useState([]);
  const [filter, setFilter] = useState('all');
  
  // Das wird bei jedem Render neu berechnet, wenn wir nicht memoize
  const filteredOrders = useMemo(() => 
    orders.filter(o => filter === 'all' || o.status === filter),
    [orders, filter]
  );

  // Diese ref wird konzeptionell bei jedem Render neu erstellt
  const handleNewOrder = useCallback((order) => {
    setOrders(prev => [order, ...prev]);
  }, []);

  useEffect(() => {
    const ws = connectWebSocket(handleNewOrder);
    return () => ws.close();
  }, [handleNewOrder]);

  return <OrderList orders={filteredOrders} />;
}

Wie Solid Signals funktionieren

Solids Modell ist grundlegend unterschiedlich. Die Component-Funktion wird einmal ausgeführt. Danach werden nur die spezifischen Ausdrücke, die ein Signal lesen, erneut ausgeführt, wenn sich dieses Signal ändert. Es gibt kein Virtual DOM Diff. Es gibt keine Reconciliation. Der Reactive Graph verfolgt genau, welche DOM-Knoten von welchen Signalen abhängen.

// Solid: Diese Funktion wird EINMAL ausgeführt
function OrderFeed() {
  const [orders, setOrders] = createSignal([]);
  const [filter, setFilter] = createSignal('all');
  
  // Das wird automatisch verfolgt – kein Dependency Array nötig
  const filteredOrders = createMemo(() => 
    orders().filter(o => filter() === 'all' || o.status === filter())
  );

  // Kein useCallback nötig – dieser Closure ist stabil
  const handleNewOrder = (order) => {
    setOrders(prev => [order, ...prev]);
  };

  // onMount statt useEffect mit leeren Deps
  onMount(() => {
    const ws = connectWebSocket(handleNewOrder);
    onCleanup(() => ws.close());
  });

  return <OrderList orders={filteredOrders()} />;
}

Was das in der Praxis bedeutet

Die Solid-Version hat keine Dependency Arrays. Kein useCallback. Kein useMemo für abgeleiteten State (obwohl createMemo existiert für teure Berechnungen – der Unterschied ist, dass es Opt-in für Performance ist, nicht erforderlich für Korrektheit).

Hier ist, was uns während der Entwicklung gebissen hat:

  1. Props zu Destructuring zerstört Reactivity in Solid. Wir hatten einen Junior-Dev, der Props in einer Solid-Component destructurte und wir verbrachten 45 Minuten damit zu debuggen, warum Updates nicht propagiert wurden. In React ist Destructuring in Ordnung, weil die ganze Funktion neu läuft. In Solid musst du auf props.value im JSX oder in einem tracked Scope zugreifen.

  2. Early Returns sind tricky in Solid. Du kannst nicht if (!data()) return <Loading /> an der Spitze einer Solid-Component machen, wie du es in React würdest. Die Component-Funktion läuft nur einmal, also würde dieser Conditional niemals neu evaluiert. Du brauchst <Show when={data()}> stattdessen.

  3. Keine Stale Closure Bugs. Das war der große Gewinn. In unserer React-Version hatten wir drei separate Stale-Closure-Bugs in der ersten Woche, bezogen auf WebSocket-Handler, die alten State captured haben. Die Solid-Version hatte null, weil Signale immer bei Zugriff gelesen werden, nicht in einem Closure captured.

Bundle Size Vergleich

Wir maßen beide Production-Builds mit der gleichen Vite-Konfiguration, gzip-Kompression und Code-Splitting-Strategie.

Metrik React 19 SolidJS 1.9 Unterschied
Framework Runtime 44,2 KB (gzip) 7,1 KB (gzip) -84%
Gesamt Initial Bundle 127,8 KB 89,3 KB -30%
Gesamt App (alle Chunks) 312,4 KB 274,1 KB -12%
Erster Chunk (Critical Path) 68,4 KB 41,2 KB -40%
Anzahl Chunks 14 14 Gleich

Solids Runtime ist dramatisch kleiner. Das ist nicht neu – Ryan Carniato hat ausgiebig darüber gesprochen. Aber was uns überraschte, war, dass der gesamt App-Größe-Unterschied sich erheblich verengte, sobald du echten Application-Code, Third-Party-Bibliotheken und Assets hinzufügst.

Die Framework-Runtime zählt am meisten für Initial Load. Und bei 7,1 KB gzip verschwindet Solid im Grunde im Rauschen. Reacts 44 KB ist spürbar, besonders auf mobilen Verbindungen.

Tree Shaking

Solid tree-shaked besser als React. Ungenutzte Solid-Primitives werden vollständig eliminiert. Mit React wird der Reconciler und die Fiber-Architektur egal ob du alle ihre Features nutzt oder nicht ausgeliefert. Wir bestätigten das, indem wir eine minimale Page in beiden built – Solids Boden ist niedriger.

Wir haben die gleiche App in SolidJS und React gebaut: Signals vs Hooks - Architektur

Rendering Performance Benchmarks

Wir laufen strukturierte Benchmarks mit Chrome DevTools Performance-Profilen, Lighthouse und Custom-Timing-Instrumentierung. Alle Tests auf einem M2 MacBook Pro mit CPU-Throttling auf 4x Slowdown eingestellt, um Mid-Range-Geräte zu simulieren.

Chart Rendering (5.000 Datenpunkte)

Metrik React 19 SolidJS 1.9
Initial Render 142ms 89ms
Re-render bei Filter-Änderung 67ms 23ms
Speicher während Render 18,4 MB 11,2 MB
DOM-Knoten erstellt 5.847 5.812

Solid war konsistent schneller bei Re-renders, weil es keinen Virtual DOM Tree diffed. Wenn ein Filter-Signal sich ändert, werden nur die Ausdrücke aktualisiert, die dieses Signal lesen. Reacts 19 Compiler-Verbesserungen halfen – der gleiche Test auf React 18 war 95ms für Re-renders – aber Solid hatte immer noch einen klaren Vorsprung.

Real-Time Order Feed (100 Updates/Sekunde)

Hier wurde es wirklich interessant. Wir haben 100 WebSocket-Nachrichten pro Sekunde in den Order Feed gepusht.

Metrik React 19 SolidJS 1.9
Frame Drops (pro 10s) 12 2
Durchschn. Paint-Zeit 8,3ms 3,1ms
Max Paint-Zeit 34ms 11ms
CPU-Auslastung (Durchschn.) 24% 9%

Solid zerquetschte diesen Benchmark absolut. High-Frequency-Updates sind da, wo Fine-Grained Reactivity die größten Dividenden zahlt. React war Updates zu bündeln (was gut ist), aber noch mehr DOM als nötig auf jedem Batch zu diffend.

Wir sollten bemerken: Reacts 19 useTransition und automatisches Batching machte das viel besser als React 18 würde. Und für die meisten echten Apps pusht man nicht 100 Updates pro Sekunde. Bei 10 Updates/Sekunde waren beide Frameworks smooth.

Komplexes Formular mit 40 Feldern

Metrik React 19 SolidJS 1.9
Keystroke Input Lag 2-4ms <1ms
Formular Submission Render 28ms 12ms
Component Re-renders pro Keystroke 3-8 1

In React würde das Tippen in ein Feld Parent-Components zum Re-render führen, wenn wir nicht alles sorgfältig memoized haben. In Solid, das Tippen in ein Feld aktualisiert buchstäblich nur den DOM-Textknoten dieses Feldes. Nichts anderes führt erneut aus.

Developer Experience und Ökosystem

Performance ist nicht alles. Du musst das Ding tatsächlich bauen, debuggen, dafür einstellen und warten.

Ökosystem-Größe (Stand Anfang 2026)

Faktor React SolidJS
npm Wöchentliche Downloads ~28M ~85K
GitHub Stars 233K+ 33K+
Stack Overflow Fragen 470K+ ~2K
UI Component-Bibliotheken 50+ reife Optionen 5-8 Optionen
Stellenausschreibungen (LinkedIn US) ~45.000 ~200
Meta-Framework Next.js (reif) SolidStart (Beta)

Das ist der Elefant im Zimmer. Reacts Ökosystem ist um Größenordnungen größer. Als wir einen Date Range Picker für Solid brauchten, mussten wir entweder einen React Porter oder schreib einfach selbst. In React hatten wir 15 Optionen, aus denen man wählen könnte.

Wir verwendeten Kobalte für zugängliche UI-Primitive in Solid, und es ist wirklich gut. Aber es ist kein Radix UI in Bezug auf Component-Coverage.

Debugging

React DevTools ist reif, gut gepflegt und etwas, das jeder Frontend-Dev kennt. Solid hat seine eigene DevTools-Extension, und sie ist ordentlich – du kannst den Signal-Graph inspizieren, was eigentlich nützlicher ist, um Reactivity-Bugs zu verfolgen, als Reacts Component-Tree-View. Aber es ist weniger poliert.

TypeScript-Unterstützung

Beide sind ausgezeichnet. Solids TypeScript-Unterstützung ist tatsächlich leicht besser für JSX, weil der Compiler mehr zur Build-Zeit handhabt. Wir hatten weniger Type-Gymnastik in der Solid-Codebase.

Production Tradeoffs, die wirklich zählen

Nach dem Bauen beider Versionen und dem Deployment der Solid-Version zum Staging (der Client wählte letztendlich React für Production – mehr dazu unten), hier sind die Tradeoffs, die wirklich zählten:

Hiring

Unser Client hat ein Team von 8 Frontend-Developern. Alle kennen React. Keiner hatte Solid verwendet. Trainingszeit-Schätzung: 2-3 Wochen für Proficiency, 2-3 Monate für Meisterschaft. Das ist ein echter Kostenfaktor. Das ist der einzelne größte Faktor bei den meisten Production-Entscheidungen, und das ist, warum wir typischerweise React oder Frameworks wie Next.js für Teams empfehlen, die häufig einstellen müssen.

Third-Party Library Kompatibilität

Wir mussten Custom Wrapper für drei Bibliotheken schreiben, die React-spezifische Integrationen hatten. Das addierte ungefähr 20 Stunden Entwicklungszeit. In einem React-Projekt existieren diese Stunden nicht.

Server-Side Rendering

SolidStart ist vielversprechend, war aber während unseres Projekts noch in Beta. Next.js ist kampferprobt. Für Projekte, wo wir Production-Grade SSR mit all den Trimmings brauchen, greifen wir immer noch zu Next.js Development oder Astro je nach dem Content-Modell.

Performance wo es zählt

Hier ist die ehrliche Wahrheit: für dieses spezielle Dashboard hatten beide Frameworks eine Production-Performance, die gut genug war. Die Solid-Version war messbar schneller, aber die React-Version war niemals langsam. Benutzer würden den Unterschied in den meisten Interaktionen nicht bemerken.

Die Ausnahme war der Real-Time-Feed bei hohen Update-Frequenzen. Wenn deine App einen Use Case wie diesen hat, ist Solids Performance-Vorteil bedeutsam, nicht nur Benchmark-Prahlerei.

Wann man SolidJS gegenüber React wählt

Nach diesem Experiment, hier ist unser ehrliches Framework für die Entscheidung:

Wähle SolidJS wenn:

  • Deine App hat High-Frequency-Reactive-Updates (Dashboards, Trading-Plattformen, Real-Time-Collaboration)
  • Bundle-Größe ist kritisch (Embedded Widgets, Micro-Frontends, Mobile-First)
  • Dein Team ist klein und bereit, Zeit in das Lernen eines neuen Paradigmas zu investieren
  • Du willst Fine-Grained Reactivity, ohne gegen das Framework zu kämpfen
  • Du baust etwas Neues und brauchst keine massive Component-Library-Ökosystem

Wähle React wenn:

  • Dein Team kennt bereits React (das alleine ist normalerweise entscheidend)
  • Du brauchst ein reifes Meta-Framework (Next.js, Remix)
  • Third-Party Library-Verfügbarkeit ist wichtig
  • Du stellst ein und brauchst einen großen Talentpool
  • Deine Apps Performance-Anforderungen sind typisch (nicht extrem)

Für unsere Headless CMS Development-Projekte dominiert React immer noch, weil CMS-Integrationen (Sanity, Contentful, Storyblok) First-Class React SDKs haben. Solid-Unterstützung existiert, aber ist oft Community-gepflegt.

Code Vergleich: Echte Patterns

Lass uns echte Patterns aus dem Projekt nebeneinander anschauen.

Datenabruf mit Loading States

React:

function Dashboard() {
  const [data, setData] = useState(null);
  const [error, setError] = useState(null);
  const [loading, setLoading] = useState(true);

  useEffect(() => {
    fetchDashboardData()
      .then(setData)
      .catch(setError)
      .finally(() => setLoading(false));
  }, []);

  if (loading) return <Skeleton />;
  if (error) return <ErrorBanner error={error} />;
  return <DashboardGrid data={data} />;
}

SolidJS:

function Dashboard() {
  const [data] = createResource(fetchDashboardData);

  return (
    <Suspense fallback={<Skeleton />}>
      <ErrorBoundary fallback={(err) => <ErrorBanner error={err} />}>
        <DashboardGrid data={data()} />
      </ErrorBoundary>
    </Suspense>
  );
}

Solids createResource mit Suspense ist wirklich elegant. React hat auch Suspense (und es ist besser geworden in React 19), aber Solids Version fühlte sich natürlicher zu arbeiten. Weniger Boilerplate, weniger State-Variablen zum Verwalten.

Bedingtes Rendering

React:

{user ? (
  <Profile user={user} />
) : (
  <LoginPrompt />
)}

SolidJS:

<Show when={user()} fallback={<LoginPrompt />}>
  {(u) => <Profile user={u()} />}
</Show>

Solids <Show>-Component existiert, weil Ternaries nicht auf die gleiche Weise funktionieren, wenn die Component-Funktion nur einmal läuft. Es dauerte, sich daran zu gewöhnen, aber das Callback-Pattern gibt dir eine eingegrenzte, Non-Null-Referenz, die nett für TypeScript ist.

List Rendering

React:

{orders.map(order => (
  <OrderRow key={order.id} order={order} />
))}

SolidJS:

<For each={orders()}>
  {(order) => <OrderRow order={order} />}
</For>

Solids <For> braucht keine Keys, weil es Array-Items per Referenz verfolgt. Wenn ein Item sich im Array bewegt, bewegt Solid den echten DOM-Knoten. React würde unmounten und remounten. Das ist, warum Solids List-Performance so gut ist.

FAQ

Ist SolidJS 2026 Production-ready?

Ja. Solid 1.x ist über zwei Jahre stabil. Unternehmen wie Cloudflare und Samsung haben es in Production verwendet. Die Kern-Bibliothek ist reif und gut getestet. Das Ökosystem um diese (SolidStart, Component-Bibliotheken) ist kleiner als Reacts, wächst aber ständig. Die Frage ist nicht, ob Solid bereit ist – es ist, ob dein Team und deine Projekt-Anforderungen sich mit seiner Ökosystem-Größe ausrichten.

Kann ich inkrementell von React zu SolidJS migrieren?

Nicht einfach. Trotz ähnlicher JSX-Syntax sind die Runtime-Modelle grundlegend unterschiedlich. Du kannst Solid-Components nicht in eine React-App (oder umgekehrt) einbetten, ohne Iframe oder Web-Component-Grenzen. Eine Migration wäre im Grunde ein Rewrite. Wenn du das überlegst, fang mit einem neuen isolierten Feature oder Micro-Frontend statt zu versuchen, existierenden React-Code zu konvertieren.

Unterstützt SolidJS Server-Side Rendering?

Ja. SolidStart stellt SSR, Streaming und Server-Functions bereit. Es ist funktional und verbessert sich schnell, aber Stand Anfang 2026 ist es immer noch weniger reif als Next.js oder Remix. Für SSR-schwere Projekte würden wir immer noch empfehlen, Next.js oder Astro je nach deinen Content-Anforderungen zu evaluieren.

Wie vergleicht sich Reacts 19 Compiler mit Solids Ansatz?

Reacts 19 Compiler (ehemals React Forget) auto-memoized Components, um unnötige Re-renders zu reduzieren. Es ist eine bedeutende Verbesserung. Aber es arbeitet immer noch innerhalb von Reacts Modell des Wieder-Ausführens von Component-Funktionen und des Diffing einer Virtual DOM. Solid überspringt beide dieser Schritte komplett. Der Compiler macht React schneller, aber ändert nicht die grundlegende Architektur. In unseren Benchmarks war React 19 mit dem Compiler etwa 30% schneller als React 18, aber immer noch langsamer als Solid auf Update-Heavy-Szenarien.

Was ist mit Preact Signals als middle ground?

Preact Signals (und der @preact/signals-react-Adapter) bringen signal-ähnliche Reactivity zum React-Ökosystem. Es ist ein interessanter Ansatz, aber es kämpft gegen Reacts Kern-Modell, anstatt damit zu arbeiten. Wir testeten es kurz und fanden Edge Cases mit Suspense und Concurrent-Funktionen. Wenn du Signals willst, gibt dir Solid die volle Erfahrung ohne den Impedanz-Mismatch.

Ist SolidJS schwerer zu lernen als React?

Wenn du bereits React kennst, wird dir Solids API bekannt aussehen – ähnlich JSX, ähnliche Patterns. Der schwere Teil ist, Reacts Mental Model zu vergessen. Du wirst nach useEffect Patterns greifen, die nicht existieren. Du wirst Props destructurieren und Reactivity unterbrechen. Du wirst Early Returns versuchen und dich fragen, warum sie nicht funktionieren. Budgetiere etwa 1-2 Wochen für einen erfahrenen React-Dev, um produktiv in Solid zu werden, und weitere Monate, um nicht mehr React-flavoured Solid zu schreiben.

Welches Framework hat bessere TypeScript-Unterstützung?

Beide haben ausgezeichnete TypeScript-Unterstützung. Solid hat einen leichten Vorsprung, weil sein Compiler engere Types in bestimmten Patterns liefern kann (wie der Callback in <Show>), und du brauchst nicht das gleiche Volumen generischer Type-Parameter, das komplexe React-Hooks manchmal verlangen. Aber ehrlich, beide sind großartig. Das sollte kein entscheidender Faktor sein.

Sollte ich SolidJS für mein nächstes Projekt verwenden?

Es kommt auf deine Einschränkungen an. Wenn du ein kleines Team bist, das etwas Performance-Sensitives baut und du bereit bist, Lernkurve zu investieren und ein kleineres Ökosystem zu arbeiten, ist Solid eine wirklich ausgezeichnete Wahl. Wenn du React-Developer einstellen musst, etablierte Component-Bibliotheken nutzen oder ein kampferprobtes Meta-Framework für Production brauchst, ist React die sicherere Wette. Es gibt keine universelle Antwort – nur die richtige Antwort für deine spezifische Situation. Wenn du die Entscheidung für dein Projekt besprechen möchtest, kontaktiere uns und wir können dir helfen, die Tradeoffs zu evaluieren.