Claude Code Qwik: Resumability, O(1) JavaScript und blitzschnelle Web-Apps mit KI

Qwik ist das Framework, das die Web-Performance-Diskussion auf den Kopf gestellt hat. Nicht mit inkrementellen Verbesserungen am bekannten Hydration-Modell — sondern mit einem grundlegend anderen Ansatz: Resumability statt Hydration. Das bedeutet O(1) JavaScript beim Start, egal wie groß die App ist. Und Claude Code ist das Werkzeug, das den Einstieg in dieses ungewöhnliche Paradigma erheblich beschleunigt.

Dieser Artikel erklärt, was Qwik wirklich anders macht, wie die zentralen Konzepte component$, useSignal, useStore und QwikCity funktionieren — und wie Claude Code dabei hilft, das mentale Modell schneller zu verinnerlichen und produktive Qwik-Apps zu bauen.

1. Resumability vs. Hydration: das grundlegende Missverständnis

Um Qwik zu verstehen, muss man zuerst das Problem benennen, das es löst. Alle gängigen Frameworks — React, Vue, Angular, Svelte — funktionieren nach dem Hydration-Prinzip: Der Server rendert HTML, der Browser lädt das JavaScript-Bundle, und dann rehydriert das Framework die Seite: es führt den gesamten Komponenten-Code erneut aus, registriert alle Event-Listener und baut den Virtual DOM neu auf. Erst danach ist die Seite interaktiv.

Das Problem: Bei komplexen Apps sind das Hunderte von Kilobytes JavaScript, die geparst und ausgeführt werden müssen — auch für Bereiche, mit denen der Nutzer nie interagiert. Das ist doppelte Arbeit: Server und Client führen denselben Code aus.

Qwik macht das anders. Es serialisiert den kompletten Anwendungszustand in das gerenderte HTML und lädt JavaScript nur dann, wenn es wirklich benötigt wird. Kein initialer JavaScript-Overhead beim Seitenstart. Die App "resumt" beim Client genau dort, wo der Server aufgehört hat — ohne alles neu aufbauen zu müssen.

"React muss beim Start die ganze Halle aufwärmen, bevor jemand tanzen kann. Qwik hat die Tänzer bereits auf der Bühne — es wartet nur auf das erste Stichwort."

2. component$ — der Einstiegspunkt in Qwik

In React schreibt man Komponenten als normale JavaScript-Funktionen. In Qwik markiert das Dollarzeichen-Suffix $ eine lazy-loadable Grenze. Claude Code versteht dieses Muster sofort und kann erklären, warum jede Qwik-Funktion, die serializiert werden soll, dieses Suffix trägt.

// Qwik-Komponente mit component$
import { component$, useSignal } from '@builder.io/qwik';

export const Counter = component$(() => {
  const count = useSignal(0);

  return (
    <div>
      <p>Aktueller Wert: {count.value}</p>
      <button onClick$={() => count.value++}>
        Erhöhen
      </button>
    </div>
  );
});

Auffällig: Auch der Click-Handler heißt onClick$, nicht onClick. Das $ signalisiert dem Qwik-Optimizer, dass dieser Handler lazy geladen werden soll. Der Handler-Code landet in einer eigenen JavaScript-Chunk-Datei und wird erst heruntergeladen, wenn der Nutzer tatsächlich klickt.

Claude Code hilft hier beim Umdenken: Wenn du React-Code mitbringst und fragst "Wie übersetze ich das nach Qwik?", analysiert Claude Code die Event-Handler, identifiziert welche Stellen das $-Suffix brauchen und erklärt, was der Qwik-Optimizer daraus macht.

3. useSignal und useStore: reaktiver Zustand in Qwik

Qwik hat zwei primäre State-Primitives: useSignal für einzelne Werte und useStore für Objekte mit mehreren Feldern. Beide erzeugen reaktive Datenstrukturen, die Qwik serialisiert und im DOM speichert.

import { component$, useSignal, useStore } from '@builder.io/qwik';

export const ShoppingCart = component$(() => {
  // Einzelwert mit useSignal
  const itemCount = useSignal(0);

  // Objekt mit useStore
  const cart = useStore({
    items: [] as string[],
    total: 0,
    currency: 'EUR',
  });

  return (
    <div>
      <h2>Warenkorb ({itemCount.value} Artikel)</h2>
      <p>Gesamt: {cart.currency} {cart.total.toFixed(2)}</p>
      <button
        onClick$={() => {
          cart.items.push('Neuer Artikel');
          cart.total += 9.99;
          itemCount.value = cart.items.length;
        }}
      >
        Artikel hinzufügen
      </button>
    </div>
  );
});

Der entscheidende Unterschied zu React: Wenn sich cart.total ändert, rendert Qwik nur die Teile der Komponente neu, die diesen Wert tatsächlich nutzen — nicht die gesamte Komponente. Das ist feingranulares Reaktivitäts-Tracking auf DOM-Ebene, ähnlich wie Solid.js, aber mit dem Vorteil der Serialisierbarkeit für Resumability.

Claude Code beim State-Design einsetzen

Claude Code kann für eine gegebene Anforderung entscheiden, ob useSignal oder useStore besser passt, und erklärt den Trade-off: useSignal für primitive Werte, bei denen Updates granular bleiben sollen; useStore für zusammengehörige Daten, bei denen tiefes Reaktivitäts-Tracking sinnvoll ist.

claude "Ich baue ein Formular mit 8 Feldern in Qwik. Soll ich useSignal
pro Feld oder einen useStore für alle Felder nehmen? Was sind die
Performance-Konsequenzen?"

4. QwikCity: Routing und Server Functions

QwikCity ist Qwiks Meta-Framework — vergleichbar mit Next.js für React oder SvelteKit für Svelte. Es bringt dateibasiertes Routing, Layouts, Error Boundaries und das mächtigste Feature: Server Functions.

// src/routes/produkte/index.tsx
import { component$ } from '@builder.io/qwik';
import { routeLoader$ } from '@builder.io/qwik-city';

// Server-seitige Datenladung mit routeLoader$
export const useProdukte = routeLoader$(async (requestEvent) => {
  const response = await fetch('https://api.example.com/produkte', {
    headers: {
      Authorization: `Bearer ${requestEvent.env.get('API_TOKEN')}`,
    },
  });
  return response.json();
});

export default component$(() => {
  const produkte = useProdukte();

  return (
    <ul>
      {produkte.value.map((produkt) => (
        <li key={produkt.id}>{produkt.name} — {produkt.preis} €</li>
      ))}
    </ul>
  );
});

Der routeLoader$ läuft ausschließlich auf dem Server. Das Ergebnis wird serialisiert und ins HTML eingebettet. Beim Client-Start muss kein API-Call wiederholt werden — die Daten sind bereits da. API-Keys und sensitive Tokens bleiben sicher auf dem Server, ohne dass man einen separaten API-Layer aufbauen muss.

Server Actions für Formulare

Neben routeLoader$ gibt es routeAction$ für Formular-Submissions und Mutationen:

import { routeAction$, Form, zod$, z } from '@builder.io/qwik-city';

export const useKontaktAction = routeAction$(
  async (data, requestEvent) => {
    // Läuft nur auf dem Server
    await sendEmail({
      to: 'info@example.com',
      subject: `Kontaktanfrage von ${data.name}`,
      body: data.nachricht,
    });
    return { erfolg: true };
  },
  zod$({
    name: z.string().min(2),
    email: z.string().email(),
    nachricht: z.string().min(10),
  })
);

export default component$(() => {
  const action = useKontaktAction();

  return (
    <Form action={action}>
      <input name="name" type="text" placeholder="Ihr Name" />
      <input name="email" type="email" placeholder="E-Mail" />
      <textarea name="nachricht" placeholder="Ihre Nachricht" />
      <button type="submit">Senden</button>
      {action.value?.erfolg && <p>Nachricht gesendet!</p>}
    </Form>
  );
});

5. Lazy Loading: wie der Qwik-Optimizer arbeitet

Das Herzstück von Qwiks Performance ist der Qwik-Optimizer: ein Build-Tool, das deinen Code analysiert und automatisch in tausende kleine Chunks aufteilt. Jede Funktion, die mit $ markiert ist, wird zu einem separaten lazy-ladbaren Modul.

Was das in der Praxis bedeutet:

• Ein Button-Click-Handler lädt nur dann JavaScript, wenn jemand klickt
• Ein Hover-Effekt lädt seinen Code nur beim ersten Hover-Event
• Ein Modal-Dialog lädt seine Logik erst, wenn das Modal geöffnet wird
• Komponenten, die außerhalb des Viewports sind, laden kein JavaScript

Claude Code kann den generierten Chunk-Graph einer Qwik-App analysieren und erklären, warum bestimmte Module zusammengefasst oder getrennt wurden. Das ist besonders hilfreich, wenn die Bundle-Größe unerwartet wächst:

claude "Analysiere diese Qwik-Komponente und erkläre, welche Teile
der Optimizer als separate Chunks extrahiert und welche zusammengeführt werden:"

6. Vergleich: Qwik vs. React, Next.js, SvelteKit

Für wen ist Qwik das richtige Framework? Ein direkter Vergleich anhand konkreter Kriterien:

• Initial Load Performance: Qwik gewinnt klar — O(1) JavaScript ist unschlagbar für content-heavy Sites mit vielen Interaktionspunkten. React/Next.js laden das komplette Bundle, SvelteKit produziert kleinere Bundles, aber kein Lazy Loading auf Funktionsebene.
• Developer Experience: React hat das größte Ökosystem, die meisten Bibliotheken, die meisten Entwickler. Qwik ist React-ähnlich genug, dass der Wechsel überschaubar bleibt — aber das $-Paradigma erfordert ein Umdenken.
• Serverseitige Features: QwikCity konkurriert direkt mit Next.js App Router und SvelteKit. Der Unterschied: Qwiks Serialisierungs-Ansatz macht Server-Client-Übergaben einfacher, weil kein separater Hydration-Schritt nötig ist.
• Bibliotheken-Kompatibilität: Nicht alle React-Bibliotheken lassen sich in Qwik einsetzen. Claude Code weiß, welche Bibliotheken Qwik-kompatibel sind und wo es Alternativen braucht.

7. Wie Claude Code den Qwik-Einstieg beschleunigt

Qwik hat eine steile Lernkurve — nicht weil die Syntax kompliziert ist, sondern weil das mentale Modell neu ist. Wo React-Entwickler reflexartig useState schreiben, müssen sie in Qwik verstehen, warum das Signal serialisiert wird und was das für den Lebenszyklus der Komponente bedeutet.

Claude Code übernimmt dabei mehrere Rollen:

Migrations-Assistent

Bestehende React-Komponenten nach Qwik portieren ist kein mechanischer Prozess — es erfordert konzeptionelle Übersetzung. Claude Code kann eine React-Komponente einlesen und eine äquivalente Qwik-Version vorschlagen, inklusive Erklärung der Unterschiede:

claude "Portiere diese React-Komponente nach Qwik. Erkläre für jeden
Unterschied, warum Qwik es anders löst:

import { useState, useEffect } from 'react';

function ProductCard({ productId }) {
  const [product, setProduct] = useState(null);
  const [loading, setLoading] = useState(true);

  useEffect(() => {
    fetch('/api/products/' + productId)
      .then(r => r.json())
      .then(data => { setProduct(data); setLoading(false); });
  }, [productId]);

  if (loading) return <div>Laden...</div>;
  return <div>{product.name}</div>;
}"

Optimizer-Erklärer

Wenn der Build unerwartet verhält oder Chunks nicht so entstehen wie erwartet, kann Claude Code die Build-Ausgabe analysieren und erklären, was der Optimizer getan hat und warum. Das spart stundenlange Debugging-Sessions in unbekannter Build-Infrastruktur.

Pattern-Bibliothek

Qwik hat eigene Patterns für häufige Aufgaben — Infinite Scroll, optimistische Updates, komplexe Formular-Validierung mit Zod, Caching-Strategien in QwikCity. Claude Code kennt diese Patterns und kann sie auf konkrete Anforderungen anwenden, statt dass man in der spärlicheren Qwik-Dokumentation sucht.

claude "Zeig mir das Qwik-Pattern für Infinite Scroll mit useVisibleTask$
und erkläre, wann useVisibleTask$ gegenüber useTask$ besser geeignet ist."

8. Ein vollständiges Beispiel: Produktliste mit QwikCity

Zum Abschluss ein vollständigeres Beispiel, das mehrere Konzepte kombiniert: serverseitige Datenladung, reaktiver Zustand, Lazy Loading und eine Server Action für den Warenkorb.

// src/routes/shop/index.tsx
import { component$, useSignal } from '@builder.io/qwik';
import { routeLoader$, routeAction$, Form, zod$, z } from '@builder.io/qwik-city';

interface Produkt {
  id: string;
  name: string;
  preis: number;
}

export const useProduktliste = routeLoader$(async () => {
  const res = await fetch('https://api.example.com/produkte');
  return (await res.json()) as Produkt[];
});

export const useWarenkorb = routeAction$(
  async (data) => {
    // Server-seitig: Artikel zum Warenkorb hinzufügen
    await addToCart({ produktId: data.produktId, menge: 1 });
    return { hinzugefuegt: true, produktId: data.produktId };
  },
  zod$({ produktId: z.string() })
);

export default component$(() => {
  const produkte = useProduktliste();
  const aktion = useWarenkorb();
  const letzterArtikel = useSignal('');

  return (
    <main>
      <h1>Unser Sortiment</h1>
      {aktion.value?.hinzugefuegt && (
        <p class="erfolg">Artikel hinzugefügt!</p>
      )}
      <ul class="produktraster">
        {produkte.value.map((p) => (
          <li key={p.id}>
            <h2>{p.name}</h2>
            <p>{p.preis.toFixed(2)} €</p>
            <Form action={aktion}>
              <input type="hidden" name="produktId" value={p.id} />
              <button
                type="submit"
                onClick$={() => { letzterArtikel.value = p.name; }}
              >
                In den Warenkorb
              </button>
            </Form>
          </li>
        ))}
      </ul>
    </main>
  );
});

Dieses Beispiel zeigt das Zusammenspiel der Konzepte: routeLoader$ lädt Daten serverseitig, routeAction$ verarbeitet Formulardaten ebenfalls serverseitig, useSignal verwaltet lokalen UI-Zustand, und das $-Suffix auf dem Click-Handler sorgt dafür, dass dieser Code nur bei Bedarf geladen wird.

Zwei verwandte Artikel, die auf diesem Thema aufbauen:

• Claude Code TypeScript — Typisierung, Generics und TypeScript-Workflows mit KI-Unterstützung
• Claude Code Debugging — Bugs in Minuten statt Stunden finden, Stack Traces systematisch analysieren

Wer tiefer in Claude Code einsteigen möchte — nicht nur für Qwik, sondern für den gesamten Entwicklungs-Workflow — findet im Claude Code Kurs einen strukturierten Einstieg auf Deutsch.