Next.js-Formulare 2026: Server Actions, React Hook Form und Conform im Vergleich

Für Next.js-Formulare gibt es 2026 drei tragfähige Wege, und die falsche Wahl kostet ein Team Wochen an Nacharbeit, sobald ein Formular über ein einzelnes Textfeld hinauswächst. Server Actions sind seit ihren Anfängen deutlich gereift, React Hook Form bleibt der Standard für alles mit echter Client-seitiger Validierung, und Conform hat sich still und leise zur Bibliothek entwickelt, die beide verbindet. Für ein B2B-SaaS-Team, das Formulare mit bedingten Feldern, Datei-Uploads und dynamischen Arrays baut, ist die Wahl keine Kosmetik. Sie bestimmt, wie viel JavaScript an den Browser ausgeliefert wird, wie Validierungsfehler den Nutzer erreichen und wie viel Code umgeschrieben werden muss, wenn ein Designer in sechs Monaten nach optimistischem UI fragt.

Dieser Beitrag vergleicht die drei Ansätze anhand desselben Formulars: ein Projekt-Erstellungsformular mit Pflichtfeldern, einem bedingten Feld, das je nach Projekttyp erscheint, und einem Datei-Upload. Ziel ist nicht, einen Gewinner zu küren, sondern zu zeigen, wo jeder Ansatz seine Berechtigung hat.

Reine Server Actions

Eine Server Action ist eine mit 'use server' markierte Funktion, die auf dem Server läuft und direkt über die action-Prop eines Formulars aufgerufen werden kann. Für ein Formular mit zwei oder drei Feldern und ohne Client-seitige Interaktivität ist das der geringste Codeaufwand.

async function createProject(formData: FormData) {
  'use server';
  const name = formData.get('name');
  const type = formData.get('type');
  // validieren, dann in die Datenbank einfügen
}

export default function NewProjectForm() {
  return (
    <form action={createProject}>
      <input name="name" required />
      <select name="type">
        <option value="internal">Intern</option>
        <option value="client">Kunde</option>
      </select>
      <button type="submit">Erstellen</button>
    </form>
  );
}

Kein Client-Bundle, kein State-Management, und das Formular funktioniert sogar mit deaktiviertem JavaScript. Der Haken zeigt sich, sobald das Formular ein bedingtes Feld braucht. Ein Feld "Kundenname" nur anzuzeigen, wenn type gleich "client" ist, erfordert Client-seitigen State, um den ausgewählten Wert zu verfolgen – womit das Formular keine reine Server-Komponente mehr ist. Bei der Fehleranzeige gibt es dasselbe Problem: Ohne useFormState (inzwischen useActionState) lädt eine fehlgeschlagene Validierung die Seite einfach neu, ohne Hinweis darauf, was schiefgelaufen ist. Server Actions funktionieren gut für einfache, überwiegend statische Formulare. Sobald ein Formular in Echtzeit auf seine eigene Eingabe reagieren muss, kämpfen reine Server Actions gegen das Framework, statt es zu nutzen.

React Hook Form mit API-Routen

React Hook Form ist seit Jahren der Standard für komplexe Formulare in React, und daran hat sich nichts geändert. Es verwaltet Feld-State, Validierung und Re-Renders auf dem Client und sendet dann an einen API-Route-Handler.

const { register, handleSubmit, watch } = useForm();
const projectType = watch('type');

async function onSubmit(data: FormValues) {
  const res = await fetch('/api/projects', {
    method: 'POST',
    body: JSON.stringify(data),
  });
  if (!res.ok) {
    // Feldfehler aus der Antwort setzen
  }
}

Das ist das richtige Werkzeug für das Projekt-Erstellungsformular, sobald bedingte Felder, Feld-Arrays oder asynchrone Validierung (zum Beispiel prüfen, ob ein Projektname schon vergeben ist) ins Spiel kommen. watch macht das bedingte Client-Feld trivial. Feld-Arrays für etwas wie "weiteres Teammitglied hinzufügen" sind ein Kernfeature. Der Nachteil: Jedes Feld, jede Fehlermeldung und jeder Ladezustand muss von Hand verdrahtet werden, und das Formular liefert sein eigenes Client-Bundle aus, unabhängig davon, wie einfach die Felder letztlich sind.

Conform

Conform liegt zwischen den beiden. Es ist darauf ausgelegt, mit Server Actions und progressiver Verbesserung zu arbeiten, gibt aber die Validierungs-Ergonomie zurück, die reinen Server Actions fehlt – inklusive vollständiger Zod-Schema-Unterstützung und strukturierter Fehlerobjekte.

const schema = z.object({
  name: z.string().min(1),
  type: z.enum(['internal', 'client']),
  clientName: z.string().optional(),
});

export default function NewProjectForm() {
  const [form, fields] = useForm({
    onValidate({ formData }) {
      return parseWithZod(formData, { schema });
    },
  });

  return (
    <form {...getFormProps(form)} action={createProject}>
      <input {...getInputProps(fields.name, { type: 'text' })} />
      <div>{fields.name.errors}</div>
      <button type="submit">Erstellen</button>
    </form>
  );
}

Das Formular wird weiterhin über eine Server Action abgesendet und funktioniert deshalb auch ohne JavaScript, aber Conform legt dieselbe Schema-Validierung sowohl auf Client als auch Server, bedingtes Rendern von Feldern gesteuert durch den Formular-State und typisierte Fehlerobjekte pro Feld darüber. Für das Projekt-Erstellungsformular bedeutet das: Dasselbe Zod-Schema validiert die Regel "Kundenname nur bei Typ Kunde" und die Einschränkung beim Datei-Upload, ohne doppelte Logik zwischen Client und Server. Der Preis ist eine steilere Lernkurve als bei React Hook Form und ein kleineres Ökosystem an Beispielen, da Conform neuer und weniger verbreitet ist.

Der Vergleich in der Praxis

Führt man dasselbe Projekt-Erstellungsformular durch alle drei Ansätze, zeigt sich ein klares Muster. Der Codeumfang ist bei reinen Server Actions am geringsten und bei React Hook Form am höchsten, sobald Fehlerbehandlung und bedingte Logik einbezogen werden, wobei Conform dazwischenliegt. Das Validierungsverhalten unterscheidet sich stärker als der Codeumfang: Server Actions validieren nur nach dem Absenden, sofern keine zusätzliche Logik ergänzt wird, React Hook Form validiert fortlaufend auf dem Client mit manuellem Abgleich zu serverseitigen Prüfungen, und Conform validiert auf beiden Seiten aus einem einzigen Schema. Die Fehleranzeige ist bei reinen Server Actions der schwächste Punkt, bei React Hook Form solide und bei Conform am stärksten von allen dreien, weil Fehler automatisch pro Feld typisiert sind.

Für ein Formular mit ein oder zwei Feldern ohne Interaktivität bleiben reine Server Actions die richtige Standardwahl. Sie liefern den geringsten Code aus und brauchen keine Abhängigkeit außer Next.js selbst. Für ein Formular mit wirklich komplexer, rein clientseitiger Interaktion, etwa Drag-and-drop-Umsortierung von Feld-Arrays oder starkem optimistischem UI, bleibt React Hook Form die flexiblere Wahl, besonders für Teams, die damit bereits vertraut sind. Für alles dazwischen, was nach unserer Erfahrung die meisten B2B-SaaS-Formulare abdeckt, lohnt sich die Einarbeitungszeit in Conform. Server-Action-Semantik mit sauberer Validierung und progressiver Verbesserung in einer Bibliothek zu bekommen, entfernt eine Fehlerkategorie, die sich sonst erst später zeigt: Client- und Server-Validierung, die still auseinanderdriften.

Testen und Migrieren zwischen den Ansätzen

Auch der Testaufwand unterscheidet sich zwischen den drei Mustern, und es lohnt sich, das vorab einzuplanen. Server Actions lassen sich als reine asynchrone Funktionen testen, indem man sie direkt mit einem gemockten FormData-Objekt aufruft, was Unit-Tests einfach hält. React-Hook-Form-Komponenten brauchen eine Rendering-Bibliothek wie Testing Library und etwas Setup, um Felder zu füllen und Validierung auszulösen, da der State im Hook liegt. Conform-Formulare liegen beim Testaufwand näher an React Hook Form, weil sich das Schema unabhängig von der Komponente mit reinen Zod-Assertions testen lässt, das gerenderte Formular aber weiterhin dasselbe Testing-Library-Setup für Interaktionstests braucht.

Ein bestehendes Formular zwischen diesen Mustern zu migrieren ist selten eine komplette Neuentwicklung. Ein mit reinen Server Actions gebautes Formular, das darüber hinausgewachsen ist, braucht meist nur das Validierungsschema extrahiert und Conforms useForm und getFormProps um das bestehende Markup gelegt, da die Server Action selbst weitgehend unverändert bleiben kann. Eine React-Hook-Form-Implementierung zu Conform zu verschieben ist mehr Aufwand, da sich die API zur Feldregistrierung deutlich genug unterscheidet, dass der Großteil des JSX angefasst werden muss – das Zod-Schema, falls schon vorhanden, lässt sich aber direkt übernehmen. Teams, die den Wechsel erwägen, sollten einplanen, dass die Schema-Arbeit wiederverwendbar ist, die Komponenten-Arbeit dagegen nicht.

Was das für dein Team bedeutet

Teams, die Individualsoftware bauen, greifen oft standardmäßig zu dem Muster, das der erste Entwickler im Projekt zufällig kannte, und diese Entscheidung bleibt dann meist für die gesamte Lebensdauer der Codebasis bestehen. Wenn deine Next.js-Anwendung eine Mischung aus einfachen und komplexen Formularen hat, verteilt über drei verschiedene Muster, ist diese Uneinheitlichkeit ein Zeichen dafür, dass die ursprüngliche Entscheidung nie überprüft wurde. Ein kurzer Architektur-Review kann klären, welches Muster zu welcher Formularklasse passt, und später eine Neuentwicklung ersparen.

Wenn dein Team eine Formular-Strategie für eine neue Webanwendung wählt oder eine bestehende, uneinheitlich gewachsene Anwendung prüft, helfen wir SaaS-Teams bei genau dieser Entscheidung als Teil umfassenderer Custom-Software-Development-Arbeit. Melde dich unter hello@wolf-tech.io oder besuch wolf-tech.io, um über deine konkreten Formulare und Rahmenbedingungen zu sprechen.