Qwik: Das Framework das JavaScript erst bei Bedarf lädt – Resumability erklärt

Was wäre, wenn eine Webanwendung beim ersten Aufruf nahezu kein JavaScript ausliefern müsste – und trotzdem vollständig interaktiv wäre? Genau das verspricht Qwik, ein Framework des Builder.io-Teams rund um Miško Hevery, dem ursprünglichen Schöpfer von AngularJS. Qwik ist keine inkrementelle Verbesserung bekannter Konzepte, sondern ein fundamentales Umdenken darüber, wie serverseitig gerenderte Anwendungen im Browser zum Leben erwachen.

Das Problem: Hydration ist verschwenderisch

Moderne Web-Frameworks wie Next.js, Nuxt oder SvelteKit nutzen Hydration: Der Server rendert HTML und schickt es an den Browser. Der Browser zeigt das HTML sofort an – das ist gut für den First Contentful Paint. Dann lädt der Browser das komplette JavaScript-Bundle, der Framework-Code "liest" das existierende HTML und macht es interaktiv, indem er Event Listener anhängt und den Anwendungszustand im Speicher aufbaut.

Dieses Hydration-Konzept hat ein fundamentales Problem: Die Arbeit wird doppelt gemacht. Der Server hat die Anwendung bereits einmal ausgeführt, um das HTML zu generieren. Der Client muss dieselbe Logik erneut ausführen, um den Zustand wiederherzustellen. Bei großen Anwendungen kann dieser Prozess Sekunden dauern – in dieser Zeit sieht die Seite zwar aus als wäre sie fertig, ist aber nicht interaktiv (Time to Interactive, TTI).

Resumability: Weitermachen statt neu starten

Resumability ist Qwiks Antwort auf dieses Problem. Statt Hydration – also dem Neustart der Anwendung im Browser – serialisiert Qwik den gesamten Anwendungszustand in das HTML, das der Server ausliefert. Der Browser kann diesen Zustand direkt lesen und "fortsetzen", ohne irgendwelche JavaScript-Dateien ausgeführt zu haben.

Das klingt abstrakt – ein Beispiel macht es greifbarer: Ein Button mit einem Click-Handler. Bei Hydration müsste der Browser das gesamte JavaScript laden, die Komponentenbaum aufbauen und dann den Event Listener am Button registrieren. Mit Qwik enthält das HTML bereits alle nötigen Informationen darüber, was beim Klick passieren soll. Das JavaScript für den Handler wird erst heruntergeladen, wenn der Nutzer tatsächlich auf den Button klickt.

Lazy Loading als Standard – alles, überall

In Qwik ist Lazy Loading der Standard, keine Ausnahme. Qwik zerteilt Anwendungscode automatisch in winzige Chunks – bis auf Funktionsebene. Der Build-Prozess analysiert den gesamten Code und erzeugt eine Karte, welche Code-Einheit für welches Ereignis benötigt wird.

Qwik verwendet dafür das Konzept des $-Suffixes, das Lazy-Loading-Grenzen markiert:

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

export const Zaehler = component$(() => {
  const zaehler = useSignal(0);

  return (
    <button onClick$={() => zaehler.value++}>
      Klicks: {zaehler.value}
    </button>
  );
});

component$ markiert die Komponente als lazy-ladbar. onClick$ markiert den Event-Handler als separaten, lazy-ladbaren Chunk. Das $ ist kein Zufall – es ist das Signal an den Qwik-Compiler, eine Lazy-Loading-Grenze einzufügen.

Qwik City: das Meta-Framework

Qwik City ist das zugehörige Meta-Framework, ähnlich wie Next.js für React oder SvelteKit für Svelte. Es bringt File-based Routing, Layouts, Server-seitige Datenlader (routeLoader$), Formularbehandlung (routeAction$) und Middleware mit sich. Ein typischer Qwik-City-Datenlader sieht so aus:

export const useProdukte = routeLoader$(async () => {
  const daten = await fetch('https://api.example.com/produkte');
  return daten.json();
});

Qwik City unterstützt Deployment auf Cloudflare Workers, Vercel Edge, Node.js und weitere Plattformen – ähnlich wie Astro mit seinem Adapter-System.

Reale Performance-Vorteile

Der Vorteil von Qwik manifestiert sich vor allem bei content-schweren Anwendungen: E-Commerce-Seiten, Nachrichtenportale, Unternehmenswebsites. Builder.io berichtete von Lighthouse-Scores nahe 100 für ihre eigene auf Qwik migrierte Website, mit einer Reduktion der Initial-JS-Größe von mehreren hundert Kilobyte auf nahezu null.

Wichtig zu verstehen: Qwik eliminiert nicht das gesamte JavaScript. Es verschiebt den Zeitpunkt des Ladens auf den Moment, in dem der Code tatsächlich benötigt wird. Bei stark interaktiven Anwendungen (z.B. Online-Editoren) lädt Qwik am Ende ähnlich viel JavaScript wie andere Frameworks – nur eben dann, wenn der Nutzer die Interaktion ausführt.

Vergleich: Qwik vs. Next.js vs. Astro vs. Remix

Interessant ist der Vergleich mit Astro: Beide verfolgen das Ziel, wenig JavaScript zu liefern, aber auf unterschiedlichen Wegen. Astro setzt auf Islands Architecture – interaktive Inseln in einem statischen HTML-Meer. Qwik hingegen macht die gesamte Anwendung resumable. Für rein content-orientierte Seiten kann Astro die einfachere Wahl sein; für Anwendungen mit komplexer Interaktivität hat Qwik die Nase vorn.

Häufig gestellte Fragen (FAQ)

Wie unterscheidet sich Resumability von Hydration konkret?

Bei Hydration führt der Browser JavaScript aus, um den Anwendungszustand neu aufzubauen und Event Listener zu registrieren. Bei Resumability serialisiert der Server den Zustand ins HTML. Der Browser liest diesen Zustand direkt aus dem DOM und registriert Event Listener nur dann, wenn ein Nutzer tatsächlich interagiert. Es wird kein JavaScript beim initialen Laden ausgeführt.

Kann ich meine bestehenden React-Komponenten in Qwik verwenden?

Qwik bietet eine qwikify$-Funktion, die React-Komponenten in Qwik-kompatible Islands-Komponenten umwandelt. Das ist nützlich für die Migration, sollte aber als Übergangslösung betrachtet werden, da diese Komponenten weiterhin hydratisiert werden müssen und die Qwik-Vorteile einschränken.

Was sind die größten Einschränkungen von Qwik?

Das Ökosystem ist deutlich kleiner als das von Next.js oder Astro. Nicht alle JavaScript-Patterns lassen sich serialisieren, was Einschränkungen bei der Code-Organisation mit sich bringt. Das $-System erfordert Disziplin und ist fehleranfällig für Entwickler, die neu in Qwik sind.

Für welche Art von Projekten ist Qwik am besten geeignet?

Qwik eignet sich besonders für öffentlich zugängliche Seiten, bei denen initiale Ladezeit und Core Web Vitals kritisch sind: E-Commerce-Plattformen, Nachrichten- und Medienseiten, Marketing-Websites und Content-portale. Für interne Tools oder Apps mit wenig öffentlichem Traffic sind die Komplexitätskosten von Qwik oft nicht gerechtfertigt.

Die Entwicklung von Qwik wird von Builder.io vorangetrieben, und das Team veröffentlicht regelmäßig tiefgehende Artikel zum Thema Performance und Resumability. Wer die theoretischen Grundlagen hinter dem Framework vertiefen möchte, findet auf dem Builder.io-Blog sowie in der Qwik-Dokumentation hervorragende Lektüre.