Next.js oder htmx + Rust. Welcher Stack wann passt

Die Entscheidung zwischen Next.js und Axum, Askama sowie htmx ist kein Wettkampf zwischen modernem JavaScript und schnellem Rust. Sie bestimmt, wer die Benutzeroberfläche besitzt.

Next.js überträgt viel Verantwortung auf das Komponentenmodell von React und bei Bedarf auf den Browser. htmx lässt den Server das endgültige HTML bestimmen und ersetzt gezielt Teile der Seite.

Unser kurzes Urteil fällt klar aus. Next.js ist eine gute Standardwahl für kundennahe Produkte und Oberflächen mit umfangreichem lokalem Zustand. Axum, Askama und htmx passen gut zu servergesteuerten CRUD-, Verwaltungs- und Workflow-Anwendungen. Eine Rust-API mit Next.js lohnt sich erst, wenn das Produkt nachweislich sowohl einen reichhaltigen Client als auch ein eigenständig anspruchsvolles oder sicherheitskritisches Backend braucht.

1. Next.js

   Umfangreicher lokaler Zustand, Editor, Karte oder unmittelbare Browserinteraktionen.

2. Axum + htmx

   Formulare, Tabellen und schrittweise Abläufe, deren Wahrheit auf dem Server liegt.

3. Rust API + Next.js

   Reichhaltige UI plus belegter Rechenbedarf, Parallelität oder mehrere Backend-Clients.

Verifizierter Stand am 22. Juli 2026

Verifizierte Versionen

• Next.js 16.2.x
• htmx 2.0.10 als stabile Linie
• htmx 4.0.0-beta5 nur als Vorschau

Die unbestätigte Aussage über ein bestimmtes Sicherheitsrelease Next.js 16.2.11 verwenden wir nicht. Vor einer Umsetzung muss das Team Versionen sperren, Release Notes lesen und aktuelle Sicherheitsmeldungen erneut prüfen.

Rust bezeichnet hier Axum für HTTP, Askama für typisierte Templates und htmx für gezielte Anfragen und HTML-Austausch. Gemeint sind weder Leptos noch Yew oder eine andere Rust-SPA. Diese Varianten folgen einem anderen Anwendungsmodell und benötigen einen eigenen Vergleich.

Wie beide Modelle arbeiten

React Server Components und HTML-Fragmente

Eine React Server Component läuft auf dem Server. Ihr Ergebnis wird im React-Transportformat übertragen und auf dem Client mit dem bestehenden Komponentenbaum verbunden.

Eine Server Component kann Daten nahe an der Quelle laden, ohne ihren eigenen JavaScript-Code an den Browser zu senden. Interaktives Verhalten braucht trotzdem eine Client-Component-Grenze, Hydrierung und Browserzustand, sobald sich die Oberfläche wie eine Anwendung verhält.

Ein htmx-Fragment ist eine gewöhnliche Serverantwort. Ein Button kann hx-post, hx-target und hx-swap deklarieren. Der Server prüft die Geschäftsregel, Askama rendert eine Zeile oder ein Panel und htmx fügt es in das DOM ein.

Der öffentliche Vertrag besteht nicht aus einem React-Baum und nicht zwingend aus JSON. Er besteht aus einer HTTP-Anfrage und HTML, dessen Struktur zum Ziel passen muss.

Keines der Modelle ist automatisch einfacher. Next.js bündelt die Komposition komplexer Oberflächen in Komponenten. htmx bündelt die fertige Ansicht auf dem Server. Die Komplexität verschwindet nicht. Sie wandert auf die Seite, die besser zu Produkt und Team passen kann.

Next.js

1. Next.js-Anfrage

   Der Browser lädt eine Route oder ruft eine Server Action auf.

2. Komponentenergebnis

   Der Server rendert Komponenten, der Client verbindet das Ergebnis mit seinem Zustand.

Axum + htmx

1. htmx-Ereignis

   Ein Klick oder Formular sendet über ein HTML-Attribut eine normale HTTP-Anfrage.

2. HTML-Fragment

   Axum prüft die Regeln, Askama rendert das Ergebnis und htmx ersetzt den gewählten Seitenbereich.

Dieselbe Rechnungsfreigabe

Umsetzung in Next.js

Nehmen wir eine Rechnungsliste. Eine berechtigte Person wählt Freigeben, der Server prüft Organisation und Dokumentstatus, speichert den Übergang und die Oberfläche zeigt den neuen Zustand. In Next.js kann ein Formular eine Server Action aufrufen.

'use server';

import { revalidatePath } from 'next/cache';

export async function approveInvoice(formData: FormData) {
  const invoiceId = String(formData.get('invoiceId') ?? '');
  const user = await requireUser();

  await invoices.approve({
    invoiceId,
    organizationId: user.organizationId,
  });

  revalidatePath('/invoices');
}

Ein echter Handler benötigt zusätzlich eine Prüfung der ID, die Berechtigung für genau diese Aktion, Schutz vor Wiederholung und eine Auditspur. Eine Server Action ist ein öffentlich erreichbarer Servereingang und keine vertrauenswürdige interne Funktion.

Nach Erfolg kann Next.js eine Route oder ein präzises Cache-Tag aktualisieren. Der Client kann vorher einen optimistischen Zustand zeigen und ihn bei einem Fehler zurücknehmen.

Die Stärke liegt in flüssiger Interaktion. Dieselbe Liste kann lokale Filter, Mehrfachauswahl, Tastenkürzel, ein Detailpanel und sofortige Berechnungen enthalten. React bietet ein klares Modell für diese Koordination.

Die Kosten entstehen an Grenzen zwischen Server und Client Components, bei der Cache-Invalidierung und bei der Kontrolle der ausgelieferten JavaScript-Menge.

Umsetzung mit Axum, Askama und htmx

In der servergesteuerten Variante sendet der Button POST /invoices/{id}/approve. Axum liest den angemeldeten Benutzer, der Anwendungsdienst prüft Organisation und Zustandswechsel und Askama liefert die aktualisierte Tabellenzeile.

use askama::Template;
use axum::{extract::{Path, State}, response::Html};
use uuid::Uuid;

async fn approve_invoice(
    State(state): State<AppState>,
    user: AuthenticatedUser,
    Path(invoice_id): Path<Uuid>,
) -> Result<Html<String>, AppError> {
    let invoice = state
        .invoices
        .approve(invoice_id, user.organization_id)
        .await?;
    let html = InvoiceRowTemplate { invoice }.render()?;
    Ok(Html(html))
}

Die Zeile kann hx-post, hx-target="closest tr" und hx-swap="outerHTML" verwenden. Nach der Antwort ändert sich nur dieses Element. AppError muss auch den Templatefehler umwandeln.

Eine Fehlerantwort sollte ein Fragment liefern, mit dem die Person sinnvoll fortfahren kann. Der Zustandswechsel gehört in den Anwendungsdienst, nicht in ein Template oder htmx-Attribut.

Dieser Weg bleibt bei Formularen und Tabellen direkt. Nach jedem Schritt besitzt der Server Wahrheit und Darstellung. Bei Mehrfachauswahl, Offlinearbeit, anspruchsvollem Drag and Drop oder mehreren gemeinsam reagierenden Panels verschiebt sich das Verhältnis.

Dann ergänzt das Team eine kleine JavaScript-Insel oder erkennt an, dass die Oberfläche inzwischen ein Client-Anwendungsmodell hat.

Entscheidungen für Betrieb und Weiterentwicklung

Browserzustand

Eine Liste mit URL-Filtern und einem Dialog funktioniert in beiden Stacks. Der Unterschied wird sichtbar, wenn Zustand sofort und ohne Serverrunde reagieren muss.

Ein Editor mit Rückgängig-Verlauf, eine Karte mit Tausenden Objekten, ein Planer mit verschiebbaren Einträgen oder ein Konfigurator mit laufender Berechnung besitzen ein natürliches Browsermodell. Next.js verbindet dafür serverseitiges Laden mit abgegrenzten Client-Inseln.

htmx ist besonders stark, wenn Datenbank, URL, Formular oder aktuelles HTML den Zustand sicher darstellen. Statt nach jeder Mutation einen Client-Store zu synchronisieren, sendet der Server eine neue Sicht auf die Wahrheit. Weniger doppelte Zustände entfernen oft ganze Fehlerklassen.

Wandern wichtige Daten jedoch in data-*-Attribute, koordiniert ein eigener Event-Bus die Seite und benötigen fünf Fragmente manuelle Aktualisierungen, verschwindet der ursprüngliche Vorteil.

API-Verträge und mobile Clients

Serverseitig gerendertes HTML ist kein Mangel, wenn die Weboberfläche der einzige Client bleibt. Für ein internes Freigabesystem kann HTML der nützlichste Vertrag sein.

Formular, Validierungsfehler und aktualisierte Zeile bilden ein konsistentes Ergebnis ohne parallele Zuordnung von DTO und Template.

Die Antwort ändert sich, wenn eine native mobile App, ein Partner oder eine öffentliche API dieselbe Fähigkeit benötigt. Ein HTML-Fragment ist kein sinnvoller allgemeiner Domänenvertrag.

JSON-Endpunkte können neben HTML-Handlern existieren, aber die Geschäftsregeln dürfen nicht in zwei Pfade kopiert werden. Beide rufen denselben Anwendungsdienst auf und erhalten Vertragstests.

Auch Next.js löst API-Design nicht automatisch. Eine Server Action ist bequem für eine bestimmte React-Oberfläche, aber kein dauerhafter Partnervertrag. Ein Produkt mit mehreren Clients braucht unabhängig vom Webrenderer eine explizite API.

Die Entscheidung über die API-Grenze sollte getrennt von der Rendering-Entscheidung fallen.

Cache und Deployment

Next.js bietet mehrere Ebenen für Caching und Invalidierung. Das hilft bei Inhaltsseiten und datenreichen Routen. Das Team muss jedoch wissen, was statisch ist, was neu validiert wird und was personenbezogen bleibt.

Fehler entstehen oft nicht durch einen defekten Cache, sondern durch unterschiedliche Annahmen über die Lebensdauer derselben Daten.

htmx schreibt keine Cachepolitik vor. Es verwendet HTTP. Vollständige Seiten und sichere GET-Fragmente können Header, Reverse Proxy oder CDN nutzen.

Persönliche Fragmente benötigen korrektes Cache-Control und Vary. Mutationen sollten eine frische Darstellung zurückgeben oder einen anschließenden Lesevorgang auslösen. Eine kleinere Abstraktion verzeiht keine falsche HTTP-Semantik.

Für beide Stacks gilt dieselbe Regel. Benennen Sie den Verantwortlichen für Aktualität und das erlaubte Alter jedes wichtigen Werts, bevor Sie einen Mechanismus wählen. Cache gehört zur Produktkonsistenz und ist keine Verzierung für Performanceberichte.

Next.js kann auf einer verwalteten Plattform oder in einer eigenen Node.js- beziehungsweise Containerumgebung laufen. Self-Hosting erfordert einen passenden Reverse Proxy, statische Assets, mehrere Instanzen, abgestimmte Caches und konsistente Build-IDs.

Das Framework übernimmt viel Anwendungsarbeit, doch die Produktionstopologie muss trotzdem geplant werden.

Eine Axum-Anwendung kann aus einem Rust-Binärprogramm mit einkompilierten Templates und einem Ordner statischer Assets bestehen. Dieser Betriebszuschnitt ist attraktiv. Kompilierung, Cross Builds, Datenbankmigrationen, Telemetrie und Abläufe für Störungen bleiben bestehen.

Weniger Runtime-Schichten bedeuten nicht, dass der Betrieb verschwindet.

Rust kann eine vorhersehbare Ressourcennutzung und genaue Kontrolle paralleler Arbeit bieten. Daraus folgt noch keine niedrigere Gesamtrechnung. Datenbank, externe APIs, Bilder und eine schlechte Abfrage bestimmen häufig die Latenz.

Deshalb nennen wir keine synthetischen Requests-pro-Sekunde-Werte aus Anwendungen, die unterschiedliche Arbeit leisten.

Sicherheit und Übergabe

Next.js und htmx teilen normale Web-Sicherheitsgrenzen. Der Server prüft bei jeder Mutation Identität, Organisation, Berechtigung und aktuellen Objektzustand. Ein verstecktes Eingabefeld, React-Prop oder DOM-Attribut ist nicht vertrauenswürdig.

Ausgaben müssen sicher maskiert werden. Bewusst eingefügtes HTML benötigt eine eng definierte Bereinigung.

Cookie-Authentifizierung verlangt eine CSRF-Bewertung anhand von Methode, Anfrageursprung und Cookie-Regeln. Ein htmx-Header oder eine Server Action ersetzt keine Autorisierung. Rust Ownership verhindert eine breite Klasse von Speicherfehlern.

Es verhindert keine Fehler bei Mandantentrennung, kein fehlerhaftes SQL und keine sensiblen Werte in Logs.

Der sicherere Stack ist derjenige, in dem das Team einen autoritativen Domänenpfad, kontrollierte Abhängigkeiten, zeitnahe Updates und brauchbare Beobachtbarkeit erhalten kann. Ein Framework liefert sichere Ausgangswerte. Es kann geschäftliche Berechtigungen nicht erraten.

Next.js profitiert von einem großen Markt für React-Entwickler. Ein Auftraggeber kann daher leichter ein Team für die Weiterentwicklung bilden. Trotzdem versteht nicht jeder React-Entwickler Server Components, Cache oder Produktionsbetrieb.

Die Übergabe braucht dokumentierte Grenzen, Entscheidungen und wiederholbare Prüfungen.

Der Rust-Markt ist kleiner und die Suche kann länger dauern. Das starke Typsystem, explizite Fehlerpfade und der Compiler verringern dafür manche unbeabsichtigte Änderung. Kennt der künftige Besitzer Rust nicht, wird ein elegantes Binärprogramm zum Organisationsrisiko.

Technische Eignung ohne verfügbaren Eigentümer ist nicht nachhaltig.

Bei individueller Softwareentwicklung bewerten wir deshalb auch, ob der Kunde das System nach der Übergabe betreiben kann. Lokale Einrichtung, Migrationen, Reaktion auf Vorfälle und Updates von Abhängigkeiten sind Teil der Architektur.

Fehlermuster, Hybrid und Stackwahl

Wo beide Ansätze scheitern

Next.js passt schlecht, wenn ein Team für einfache Formulare eine große Client-Anwendung baut, nur weil es React kennt. Unnötige Hydrierung, doppelter Zustand, komplizierte Invalidierung und Server-Action-Grenzen verdecken einen einfachen Geschäftsablauf.

Das Framework entwickelt sich zudem schnell genug, dass Upgrades laufende Aufmerksamkeit verlangen.

Ein weiterer Fehler entsteht, wenn Next.js ohne klare Module zugleich zufällige Integrationsschicht und Domänenbackend wird. UI, Autorisierung, Anbieteraufrufe und lange Jobs vermischen sich in Routen.

Das Produkt besitzt dann weder einen klaren mobilen Vertrag noch einen offensichtlichen Ort für sichere Tests der Geschäftsregel.

Wo htmx + Rust scheitert

Rust kann ein Team bremsen, das Produkt und Sprache gleichzeitig entdeckt. Der Compiler erkennt technische Widersprüche, aber er entscheidet nicht, ob eine Ansicht nützlich ist. In einer frühen Suchphase können Typen und Kompilierungszyklen teurer sein als das aktuelle Risiko.

htmx scheitert, wenn Fragmente eine unsichtbare Client-Zustandsarchitektur bilden. Eine Antwort verändert mehrere Ziele, Ereignisse lösen weitere Ereignisse aus und eigenes JavaScript sammelt sich an. Der Ablauf wird schwer nachvollziehbar.

React ist an diesem Punkt keine Niederlage, sondern eine zutreffende Beschreibung der Oberfläche.

Auch der kleinere Markt für Menschen mit Rust-, Servertemplate-, Progressive-Enhancement- und Barrierefreiheitswissen bleibt ein Risiko. Eine einfache Runtime kann eine aufwendige Übergabe verbergen.

Wann Rust-API + Next.js sinnvoll werden

Der Hybrid passt, wenn zwei unabhängige Anforderungen belegt sind. Das Frontend besitzt reichhaltigen Zustand und profitiert vom React-Ökosystem. Das Backend verarbeitet rechenintensive Aufgaben, strenge Latenzziele, hohe Parallelität oder einen eigenen Vertrag für mehrere Clients.

Teams können diese Grenze unabhängig testen, versionieren und betreiben.

Der Hybrid ist keine Versicherung gegen eine Entscheidung. Er bringt zwei Toolchains, Netzwerkausfälle, ein API-Schema, Authentifizierung zwischen den Schichten, korrelierte Logs und koordinierte Änderungen.

Schreibt eine Rust-API nur ein Formular in die Datenbank und bleibt Next.js ihr einziger Client, bezahlt das System Verteilung ohne Unabhängigkeit.

Ein Produkt kann in einem Stack beginnen und Domänengrenzen bewahren. Dasselbe Prinzip erklärt unser Vergleich von modularem Monolithen und Microservices.

Eine API sollte aufgrund von Verantwortung und Messwerten entstehen, nicht für die Symmetrie eines Architekturbilds.

Entscheidungsmatrix und Übergabe

Bei Rise verwenden wir eine praktische Heuristik. Bestehen ungefähr 80 Prozent der Ansichten aus Formularen, Tabellen und aufeinanderfolgenden Abläufen, deren Zustand natürlich auf dem Server lebt, verdienen Axum, Askama und htmx eine ernsthafte Prüfung.

Das ist kein wissenschaftlicher Grenzwert und keine allgemeine Regel. Es ist ein Signal dafür, dass React möglicherweise ein Problem löst, das das Produkt nicht hat.

Entsteht ein wesentlicher Teil des Werts durch unmittelbare Manipulation im Browser, ist Next.js die sicherere Standardwahl. Werden beide Eigenschaften benötigt, sollte zuerst der echte Domänenvertrag feststehen und erst danach ein Hybrid geprüft werden.

Prüfung vor der Entscheidung

Beginnen Sie mit den Entscheidungsgrundlagen.

• die drei anspruchsvollsten Interaktionen,
• alle erwarteten Clients,
• die Betriebsgrenzen.

Bauen Sie danach einen dünnen vertikalen Schnitt eines typischen Ablaufs.

Messen Sie Browserzustand, Netzwerkschritte, Fehlerverhalten, übertragene Assets und die Zeit für eine sichere Änderung. Diese Daten sind wertvoller als ein allgemeiner Benchmark.

Klären Sie auch die Verantwortung. Wer aktualisiert das Framework, reagiert auf Vorfälle, versteht Migrationen und kann das Produkt in zwei Jahren übernehmen. Unser Leitfaden zur Auswahl eines IT-Partners zeigt, warum diese Antworten in Angebot und Übergabeplan gehören.

Schließen Sie die Entscheidung erst nach dem vertikalen Schnitt und einer Einigung über die Verantwortung ab. Die Architektur ist tragfähig, wenn das künftige Team ihre Grenzen erklären, messen und sicher verändern kann.