Frontend-Stack für Solo-Gründer: Astro, Next.js, React, Tailwind und shadcn/ui auswählen

Im Projekt liegen vier Seitentypen: /blog, /tools/image-resizer, /dashboard/settings und /pricing. Soll alles in eine Next.js-App oder der Astro-Blog vom Next.js-Dashboard getrennt werden? Ein laufender Astro-Blog bekommt Login, Zahlung und Verlauf, während ein Next.js-Projekt mit nur 20 Markdown-Artikeln trotzdem Cache-Regeln, Server/Client Components und Deployment verstehen muss.

Die Frontend-Wahl eines Solo-Unternehmens ist kein Wettbewerb um das beste Framework. Seitentyp, dynamische Daten und Wartungskosten entscheiden über Framework, Repository-Grenze und die Verantwortung für kopierten shadcn/ui-Code. Entscheidend sind die Grenzen: wann Astro Islands genügen, wann die App-Router-Komplexität teurer als ihr Nutzen wird und wann React + Vite einfacher ist.

Backend, Deployment, Datenbank, Zahlung und Authentifizierung bleiben Themen der folgenden Artikel.

Entscheidungstabelle für das Framework

Beginne mit dem Seitentyp statt mit Popularität.

Mehrere Seitentypen in einem Produkt

Bei 80 Prozent Content und 20 Prozent Dashboard kann Astro die Hauptanwendung bleiben; das Dashboard läuft als React Islands oder separate Next.js-App.

Bei 80 Prozent Anwendung und 20 Prozent Blog übernimmt Next.js, während der Blog statisch generiert wird.

Bei einer etwa hälftigen Verteilung schaffen eine Astro-Content-App und eine Next.js-Dashboard-App eine klare Grenze. Auch ein Monorepo kann diese Grenze erhalten.

Die Trennung erhöht Deployment- und Abhängigkeitsaufwand. Sie verhindert jedoch, dass Cache- und Rendering-Regeln einer Oberfläche überall gelten.

Hinweis zu Wartungskosten

Caching, Komponenten-Grenzen und die Unterschiede zwischen Vercel, Cloudflare und Self-Hosting müssen geprüft werden. Bei wenigen dynamischen Seiten können Astro oder React + Vite günstiger zu warten sein.

Der Vergleich von Astro und Next.js behandelt die technischen Details.

Content-Seiten: Astro und Islands

Astro richtet sich an Blogs, Dokumentation, Marketing und andere content-getriebene Seiten. Server-first und zero JS by default bedeuten, dass HTML beim Build oder auf dem Server entsteht und nur ausdrücklich interaktive Komponenten JavaScript im Browser laden.

Content Collections organisieren, validieren und typisieren Markdown oder strukturierte Daten. Frontmatter und Abfragen nach Datum, Tag oder Kategorie lassen sich beim Build prüfen.

Islands: statisches HTML mit lokaler Interaktion

Der größte Teil der Seite bleibt HTML; nur ein kleiner interaktiver Bereich wird zur Island. client:load und client:visible legen den Ladezeitpunkt fest.

Ein Absende-Button kann allein als React-Komponente mit client:load laufen.

Ein Theme-Schalter kann localStorage lesen und CSS-Variablen aktualisieren.

Ein Bildbetrachter kann erst mit client:visible geladen werden.

So muss nicht die ganze Seite hydriert werden, nur weil sie ein Formular oder ein kleines Tool enthält.

Wann Astro nicht alles tragen sollte

Wenn fast jede Route Identität prüft, private Daten lädt, großen gemeinsamen Zustand teilt oder komplexes Client-Routing braucht, ist Astro nicht mehr automatisch die einfachste Basis. Ein Dashboard aus vielen authentifizierten Islands passt meist besser in Next.js oder eine eigenständige React-App.

Die Astro-5-Lighthouse-Praxis zeigt Content Collections und Islands in einer Content-Seite.

Tools und interaktive Produkte: React + Vite oder Next.js

Ein Tool konzentriert sich oft auf eine Aktion; ein interaktives Produkt bringt mehrere Routen, gemeinsamen Zustand, Kollaboration oder einen Editor mit.

Wann React + Vite passt

React + Vite eignet sich für eine Client-SPA oder ein einzelnes Tool ohne Server-Rendering.

Ein Bildkompressor verarbeitet Dateien im Browser und bietet das Ergebnis zum Download an.

Ein JSON-Formatter analysiert Eingaben lokal.

Vultr - Hochleistungs-NVMe-Cloud-Server mit 32 Standorten weltweit, Docker per Klick

Preise ansehen →Anzeige

Ein Markdown-Editor kombiniert Bearbeitung, Vorschau und localStorage.

Statisches Deployment und fehlende Next.js-Cache-Grenzen vereinfachen die Wartung. Für wichtige Such-Landingpages braucht eine reine Client-App jedoch eine eigene SEO-Strategie.

Wann Next.js passt

Next.js passt bei Server-Rendering, mehreren Routen oder gemischtem Rendering.

Startseite, Tool und Ergebnis können eigene servergerenderte Routen sein.

Erklärende Suchseiten können über SSG oder SSR indexierbar bleiben.

Ein Produkt kann statische Einführungen und dynamische private Ergebnisse kombinieren.

Bedingungen für React + Vite

Die Kernaktion läuft mit Browser APIs, localStorage oder Canvas.

Das Tool soll ohne Node.js-Runtime statisch deployt werden.

Routing, Cache und SSR von Next.js werden nicht gebraucht.

Eine klare Trennung zwischen Client und Backend ist leichter zu warten.

Sind Suche und Server-Routen zentral, muss ihr Nutzen gegen die zusätzliche Next.js-Komplexität abgewogen werden.

React 19 Actions vertieft Formulare und asynchrone Aktionen.

SaaS-Dashboards: Server und Client Components in Next.js

Der App Router trennt Serverarbeit und Browserinteraktion. 'use client' markiert die Client-Grenze.

Server Components und Client Components

Server Components laufen auf dem Server oder beim Build und vergrößern nicht den JavaScript-Bundle ihrer Komponentenlogik.

Sie passen zu statischem Inhalt, Datenbankabfragen und API-Aufrufen.

localStorage, window, useState, useEffect und onClick stehen dort nicht zur Verfügung.

Client Components laufen im Browser und unterstützen Interaktion, Zustand und Browser APIs.

Sie passen zu Formularen, Schaltern und Live-Updates.

'use client' steht am Dateianfang der Grenze.

Server Components können Client Components importieren. Umgekehrt ist ein direkter Import nicht möglich; servergerenderter Inhalt kann jedoch als renderbarer Inhalt übergeben werden.

Einsatz im SaaS-Dashboard

Der App Router passt zu Authentifizierung, dynamischen Daten und vielen Formularen.

Einstellungen lesen Nutzerdaten und schreiben Präferenzen.

Bestellseiten listen Daten, zeigen Details und ändern Zustände.

Analysen laden geschützte Daten auf dem Server und interaktive Diagramme im Browser.

Server Components können direkt mit einer Datenschicht arbeiten, wenn Identität und Rechte zentral sind.

Hinweis zu Wartungskosten

Statisches und dynamisches Rendering, revalidate, Komponenten-Grenzen und Runtime müssen zur eingesetzten Next.js-Version passen. Aktuelle Dokumentation ist verlässlicher als alte Snippets.

Bei nur wenigen dynamischen Seiten kann React + Vite mit einem getrennten Node.js- oder Supabase-Backend einfacher sein.

Die Next.js-App-Router-Serie behandelt Routing, Migration, Middleware, Auth und Dark Mode einzeln.

Styling-Schicht: Tailwind und Utility First

Utility First kombiniert kleine Klassen direkt in HTML oder JSX. In <div class="bg-blue-500 text-white p-4 rounded-lg"> steuert jede Klasse einen Teil des Stils.

Tailwind ist eine Zusammenarbeitsschicht, kein Ersatz für Produktdesign.

Es reduziert die Benennung eigener CSS-Klassen.

Styles bleiben nahe an ihrem Markup und driften seltener auseinander.

Menschen und Coding Agents erhalten eine gemeinsame Sprache für Layoutänderungen.

KiloClaw - Managed OpenClaw für Unternehmen: AI-Agent-Orchestrierung und smartes Modell-Routing

Jetzt starten →Anzeige

Tailwind erzeugt keine Designqualität

Farben, Typografie, Abstände und Radien brauchen konsistente Regeln.

Produkttokens sind besser als zufällige Standard-Utilities.

Wiederholte Klassen für Buttons, Karten und Zeilen gehören in Komponenten.

Ohne diese Grenzen wird das Markup dichter, aber das Produkt nicht konsistenter.

Tailwind ist vom Framework unabhängig

Tailwind funktioniert mit Astro, Next.js und React + Vite. Der aktuelle Vite-Weg von Tailwind CSS v4 nutzt @tailwindcss/vite und @import "tailwindcss";; Astro kann dasselbe Plugin verwenden. Vor der Umsetzung gilt die aktuelle Framework-Anleitung.

Komponenten-Schicht: Eigentum und Integration bei shadcn/ui

shadcn/ui versteckt keine feste Implementierung in einem klassischen Paket. Die CLI kopiert Quellcode ins Projekt, das ihn anschließend besitzt.

Der Quellcode gehört zum Projekt

Upstream-Updates ändern kopierte Komponenten nicht automatisch.

Tastaturbedienung, ARIA und Screenreader müssen in den tatsächlichen Kombinationen getestet werden.

Farben, Radien und Abstände müssen zum Designsystem passen.

Validierung, Übermittlung und Geschäftslogik bleiben Anwendungscode.

Sichtbarer, anpassbarer Code ist der Vorteil; Updates, Accessibility, Theme und Zustände sind die Gegenleistung.

shadcn/ui und Tailwind

Die aktuellen Anleitungen für Astro und Next.js setzen Tailwind voraus. Tailwind liefert die Stylingsprache, shadcn/ui den zu besitzenden Komponentenquellcode.

Geeignete Einsatzfälle

SaaS-Dashboards, Einstellungen und formularreiche Seiten profitieren von Buttons, Inputs, Selects, Dialogen und Tabellen.

Einstellungen können Controls und Fehlermeldungen wiederverwenden.

Registrierung, Login und Checkout nutzen die Primitives, behalten aber Validierung und Zustand im Produkt.

Bei einer bestehenden Komponentenbibliothek oder einem vollständigen Markensystem ist der Nutzen geringer.

Integration in Astro

Für React-Komponenten ist die React-Integration erforderlich.

Tailwind liefert die Styles.

Die Komponenten passen zu lokalen Formularen und Dialogen, nicht als Grund, jede Content-Seite zur React-App zu machen.

Das offizielle Astro-Template richtet derzeit Tailwind und React ein; die aktuellen CLI-Schritte sollten vorab geprüft werden.

Integration in Next.js

shadcn/ui bietet ein Next.js-Template und einen Weg für bestehende Projekte.

Komponenten gehören entsprechend ihrer Interaktion auf die richtige Server/Client-Seite. Eine ganze Seite muss deshalb nicht zur Client Component werden.

CLI, Presets und Registry können sich ändern.

Wann shadcn/ui nicht passt

Wenn ein vollständiges Designsystem statt einzelner Primitives gebraucht wird.

Wenn das Projekt Quellcode, Updates, Accessibility und Themes nicht besitzen will.

Wenn Ant Design, Material UI oder eine interne Bibliothek bereits genügt.

Wenn die Content-Seite kaum Formulare oder Dashboard-UI hat.

Die tatsächlichen Wartungskosten für Solo-Gründer

Neben Seitentyp und Daten bestimmen Framework-Komplexität, Komponentenbesitz und die Prüfung von KI-Code den langfristigen Aufwand.

Next.js warten

Nicht passende Rendering- und Cache-Regeln können alte Daten ausliefern.

Server/Client-Grenzen legen fest, wo Zustand und Datenzugriff leben.

Vercel, Cloudflare und eine eigene Node.js-Runtime müssen getrennt bewertet werden.

Alibaba Cloud - Top-Wahl für Entwickler, exklusiv 15 % Rabatt auf Lighthouse-Server

15 % Rabatt sichern →Anzeige

Bei überwiegend statischen Seiten kann dieser Prüfaufwand den Nutzen übersteigen.

shadcn/ui warten

Upstream-Fixes und Updates müssen geprüft werden.

Tastatur, ARIA und Screenreader brauchen Produkttests.

Farben, Dichte und Abstände müssen zu den Tokens passen.

Validierung, Übermittlung und Zustand bleiben eigene Logik.

Wer diese Verantwortung nicht will, wählt eher eine Paketbibliothek oder wenige eigene Primitives.

KI-generierten Frontend-Code prüfen

React-, Next.js- und shadcn/ui-Beispiele sind reichlich vorhanden, trotzdem bleibt die Abnahme.

Ein Agent kann unnötige Server/Client-Schichten erzeugen.

Er kann Cache-Regeln verwenden, die nicht zur Version oder Route passen.

Er kann Design-Tokens und Interaktionszustände übersehen.

KI spart Implementierungszeit, aber nicht Architektur-, Accessibility- und visuelle Prüfung.

Mehrere Frameworks in einem Produkt

Astro für Content und Next.js für das Dashboard schaffen eine klare Grenze, benötigen aber Abhängigkeiten, Konfiguration und CI/CD für zwei Apps.

Auch Routing wie blog.example.com und app.example.com muss betrieben werden.

Beide Apps können in einem Monorepo liegen. Content-lastige Produkte bleiben überwiegend Astro, App-lastige überwiegend Next.js, ausgeglichene Produkte nutzen zwei klare App-Grenzen.

Nächste Schritte und weitere Artikel

Veröffentlichte Artikel

Blog-Frameworks auswählen vergleicht Hugo, Astro und Hexo.

Astro 5 und Lighthouse 100 behandelt Collections, Islands und Performance.

Astro vs Next.js vergleicht Architektur und Rendering.

React 19 Actions vertieft Formulare und asynchrone Aktionen.

Next.js-App-Router-Serie

Routing, Migration, Middleware, Auth und Dark Mode werden in separaten Artikeln für SaaS-Dashboards behandelt.

Folgende Artikel dieser Serie

Dies ist Teil fünf der Solo-Founder-Tech-Stack-Serie. Danach folgen Backend-Optionen mit Node.js, Python, Go, Supabase und eigenen APIs.

Weitere Artikel vergleichen Cloudflare, Vercel, Self-Hosting und Container.

Bei Datenbanken geht es um PostgreSQL, Supabase, PlanetScale und MongoDB.

Die Authentifizierung vergleicht verwaltete und selbst gebaute Ansätze.

Nach der Seiteneinteilung müssen Backend und Deployment die gewählte Frontend-Grenze unterstützen.