Web-App-Stack 2026 — Welche Technologie für welches Projekt

Die Stack-Entscheidung am Anfang eines Web-App-Projekts entscheidet über drei Jahre Betriebskosten, Wartbarkeit und die Fähigkeit, später Entwickler nachzubesetzen. 2026 ist diese Entscheidung gleichzeitig einfacher und schwieriger geworden: einfacher, weil sich um Next.js und React 19 ein stabiles Default-Ökosystem gebildet hat, das in den meisten Business-Szenarien funktioniert; schwieriger, weil ernstzunehmende Alternativen — SvelteKit 2, Solid, Astro, Hono auf Cloudflare — in spezifischen Anwendungsfeldern technisch klar überlegen sind. Dieser Artikel ordnet die wichtigsten Bausteine eines modernen Web-Stacks ein und zeigt, welche Technologie für welches Projekt sinnvoll ist. Am Ende steht der Default-Stack, mit dem wir bei Reepa Solutions die meisten Kundenprojekte umsetzen — als Referenz, nicht als Dogma. Für die Einordnung in unsere gesamte Softwareentwicklungs-Strategie siehe den Softwareentwicklungs-Guide.

Was eine moderne Web-App 2026 ausmacht — und warum das wirtschaftlich zählt

Eine Business-Web-App im Jahr 2026 sieht in den Erwartungen der Nutzer und Auftraggeber anders aus als 2020. Time-to-Interactive unter zwei Sekunden ist nicht mehr nice-to-have, sondern Standard. Mobile-Nutzung übersteigt in fast allen B2C-Szenarien die Desktop-Nutzung, und auch im B2B-Mittelstand wird ein nennenswerter Teil der Logins über Smartphone und Tablet abgewickelt. Barrierefreiheit nach BFSG ist seit Mitte 2025 für viele Anbieter Pflicht und wird von Kunden zunehmend in Lieferanten-Audits abgefragt. Datenschutz-Anforderungen — DSGVO, Schrems-II-konforme Hosting-Standorte, Cookie-Minimierung — sind harte Kostenfaktoren, die schon die Stack-Auswahl beeinflussen.

Hinzu kommen drei wirtschaftliche Hebel, die in jeder Stack-Entscheidung berücksichtigt werden sollten. Erstens der Personalmarkt: ein Stack ist nur dann eine gute Entscheidung, wenn in drei Jahren noch Entwickler dafür zu bekommen sind. Zweitens die Hosting-Kosten: die Auswahl zwischen Serverless, Edge und klassischem Container-Hosting verändert die laufenden Kosten um den Faktor fünf bis zehn. Drittens die Betriebskosten: ein TypeScript-First-Stack mit guter Test-Infrastruktur reduziert Wartungs- und Fehlerbehebungs-Aufwand spürbar, was sich über die Projekt-Lebensdauer summiert.

Eine Beobachtung aus unserer Praxis: in den meisten mittelständischen Projekten ist die Anschaffungs-Phase deutlich kürzer als die Betriebs-Phase. Ein Projekt, das in vier Monaten gebaut wird, wird typischerweise drei bis fünf Jahre betrieben, gepflegt und erweitert. Stack-Entscheidungen, die das nicht berücksichtigen — etwa exotische Frameworks, die spaßig zu bauen sind, aber wenig Wartungs-Personal haben — produzieren spätere Sanierungs-Kosten in sechsstelliger Höhe. Die folgende Übersicht ist deshalb pragmatisch geschrieben, nicht trendsetzend.

Frontend — die ernstzunehmenden Optionen

Im Frontend stehen 2026 fünf Optionen zur Diskussion, die für seriöse Projekte tragen. Jede hat ein klares Profil.

Framework	Profil	Wann sinnvoll
React 19	Größtes Ökosystem, Server Components als Standard, gute Tooling-Lage, höchste Personal-Verfügbarkeit	Default für Business-Apps mit mehreren Entwicklern und mehrjährigem Lebenszyklus
Vue 3.5	Sehr gute Developer-Erfahrung, klare Reaktivität, in DACH und Asien stark verbreitet	Teams mit Vue-Hintergrund, Inhouse-Tools mit langer Pflege
SvelteKit 2	Kleinste Bundle-Größen, weniger Boilerplate, sehr gute Performance, kleineres Ökosystem	Performance-kritische Frontends, kleine Teams, Inhouse-Tools
Solid	Feingranulare Reaktivität ohne Virtual DOM, beste Render-Performance, sehr klein	Dashboard-lastige Apps mit vielen Updates pro Sekunde, Visualisierungen
Astro	Content-zentriert, Islands-Architektur, mehrere UI-Frameworks pro Seite mischbar	Marketing-Sites, Blogs, Dokumentation, SEO-Cluster wie diese Seite

Die Realität: für Business-Web-Apps im deutschen Mittelstand ist React 19 in 70 bis 80 Prozent der Projekte die richtige Wahl, weil der Personalmarkt entscheidet. Für interne Tools, Performance-kritische Frontends oder Teams mit klarem Svelte-Profil ist SvelteKit eine sehr gute Alternative. Astro nutzen wir bei Reepa selbst nicht für die Hauptanwendung, aber für Content-Seiten und Cluster — die statische Auslieferung ist für SEO-Cluster und Marketing klar überlegen.

Meta-Frameworks — wer übernimmt Routing, Rendering, Data-Fetching

Ein nacktes Frontend-Framework reicht für seriöse Web-Apps nicht. Routing, Server-Rendering, Data-Fetching, Build-Pipeline und Deployment-Integration kommen aus einem Meta-Framework. 2026 sind vier Optionen relevant.

Next.js 16 bleibt der Default für React-Projekte. Cache Components, partielles Pre-Rendering und Server Components sind ausgereift, das Tooling rund um Vercel hochintegriert, das Ökosystem an Drittanbieter-Bibliotheken größer als bei jedem Konkurrenten. Schwächen: hohe Komplexität, viele neue Konzepte pro Major-Release, Bindung an Vercel oder eigene Infrastruktur ist real. Für mittelständische Business-Apps trotzdem die risikoärmste Wahl.

Nuxt 4 ist das Vue-Pendant zu Next.js und 2026 in vielen Disziplinen ebenbürtig. Wer in einem Vue-Team ist, hat keinen Grund zu wechseln. Server Components, Datenmodell, Module-Ökosystem und Hosting-Integration sind solide.

Remix / React Router 7 ist nach der Verschmelzung zu React Router 7 wieder einen Blick wert. Der Ansatz — Routing als Datenmodell, Forms als first-class-Mechanismus — ist konzeptionell sauberer als Next.js, das Ökosystem ist aber spürbar kleiner und die Hosting-Optionen außerhalb von Vercel und Cloudflare Workers weniger ausgereift.

SvelteKit 2 ist das mit Abstand schnellste und konzeptionell klarste Meta-Framework. Build-Output ist klein, das mentale Modell überschaubar, Server-Funktionen und Form-Actions elegant gelöst. Wenn das Team Svelte ohnehin nutzt: keine bessere Wahl.

Pragmatische Empfehlung: Next.js für die meisten React-Projekte, Nuxt wenn Vue gesetzt ist, SvelteKit wenn Performance oder Team-Profil das nahelegen. Remix nur dann, wenn das Team ein klares Profil dafür hat.

Styling — Tailwind, Component-Libraries oder eigenes Design-System

Im Styling-Layer hat sich 2026 ein klarer Konsens entwickelt: Tailwind CSS 4 ist der Standard für Utility-First-Styling, und darüber hinaus haben sich zwei Patterns etabliert.

• Tailwind 4 als BasisSchnelles Stylen, einheitliches Design-Token-Modell, sehr gute Editor-Integration, kleiner Build-Output. Nahezu jedes neue Projekt startet 2026 mit Tailwind 4 als Fundament, unabhängig vom Frontend-Framework.
• shadcn/ui für ReactKein Paket, sondern eine Sammlung kopier-fähiger Komponenten auf Basis von Radix Primitives und Tailwind. Volle Kontrolle über den Code, kein versteckter CSS-in-JS-Layer, leicht anpassbar an eigene Design-Vorgaben. Der pragmatische Default für React-Apps im Business-Umfeld.
• Headless UI / Radix PrimitivesFür Teams, die ein eigenes Design-System aufbauen, sind ungestylte, voll zugängliche Primitives die richtige Basis. Sie liefern die Logik — Dialog, Combobox, Toast, Tabs — der Look kommt aus dem eigenen System.
• CSS-Modules als NotausgangIn Projekten ohne Tailwind oder mit sehr eigenständigem Design-Anspruch bleiben CSS-Modules der saubere Default. Vorhersehbar, framework-agnostisch, ohne Build-Magie.

Klassisches CSS-in-JS — emotion, styled-components — verliert weiter an Boden, weil es im Zusammenspiel mit Server Components Probleme bereitet und die Bundle-Größe unnötig wachsen lässt. Für neue Projekte nicht mehr unsere Empfehlung.

Backend — Node, Deno, Bun und die schlanken Frameworks

Backend-Entscheidungen haben sich 2026 spürbar diversifiziert. Node.js bleibt das stabile Rückgrat, hat aber ernstzunehmende Konkurrenz bekommen — und vor allem haben sich schlanke Web-Frameworks etabliert, die das Express-Modell ablösen.

Node.js bleibt der Default. Reife, Ökosystem-Größe und Hosting-Verfügbarkeit sind unschlagbar. Für API-Backends, Web-App-Server und Background-Worker ist Node weiterhin die risikoärmste Wahl.

Bun ist 2026 produktionsreif und in vielen Disziplinen — Start-Zeit, Paket-Installation, eingebauter Test-Runner — Node spürbar voraus. Wir setzen Bun für Build-Pipelines und CLI-Tools ein, in produktiven HTTP-Servern bei Kunden bleiben wir defensiv bei Node, weil der Ökosystem-Vorsprung dort noch Jahre halten wird.

Deno ist technisch reif, aber im DACH-Mittelstand weiter Nische. Wer schon einen Deno-Hintergrund hat, bekommt ein klares Sicherheits-Modell und sehr guten TypeScript-Support out-of-the-box. Für neue Projekte ohne Vorgeschichte empfehlen wir es selten als Default.

Auf der Framework-Ebene haben sich zwei schlanke Alternativen zu Express etabliert:

• Hono — ultraleichtes Web-Framework, läuft auf Node, Bun, Deno, Cloudflare Workers, Vercel Edge. Erste Wahl, wenn der Backend-Code portabel zwischen verschiedenen Runtimes laufen soll oder wenn Cloudflare-Workers das Hosting-Ziel sind.
• Elysia — Bun-zentriertes Framework mit sehr starker TypeScript-Inferenz und automatischer OpenAPI-Generierung. Ideal für Teams, die Bun ohnehin nutzen und maximale Typsicherheit zwischen Backend und Frontend wollen.

Express bleibt für bestehende Codebasen vertretbar, ist aber für neue Projekte nicht mehr unsere Empfehlung — es fehlt an moderner Async-Middleware-Story und an guter TypeScript-Inferenz. Wer in Next.js arbeitet, hat ohnehin Route-Handler und Server Actions als integriertes Backend und braucht oft gar kein separates Framework.

TypeScript end-to-end — der wichtigste Hebel

Wenn wir nur eine einzige Empfehlung für 2026 geben dürften, wäre es diese: TypeScript end-to-end. Das bedeutet TypeScript im Frontend, im Backend, in geteilten Bibliotheken und in den Datenbank-Modellen — mit echter Typ-Weitergabe zwischen den Schichten. Die Effekte sind dramatisch: deutlich weniger Laufzeitfehler in Produktion, schnelleres Refactoring, dokumentierte Schnittstellen ohne separates Schema-Dokument, automatische API-Vervollständigung im Frontend.

Die Praxis-Umsetzung ist 2026 deutlich einfacher als vor drei Jahren. Drizzle ORM liefert Typen direkt aus dem Datenbank-Schema. tRPC oder Zod-Schemas hinter Server Actions geben dem Frontend exakt die Typen, die das Backend tatsächlich produziert. Werkzeuge wie Hey API generieren TypeScript-Clients aus OpenAPI-Specs, sodass auch externe API-Anbindungen typisiert sind. Tieferer Einblick in unsere konkrete Setup-Empfehlung im Cluster zum TypeScript-Stack 2026.

Datenbanken im Web-Stack

Die Datenbank ist der Teil des Stacks mit der höchsten Persistenz — sie wird länger leben als das Frontend-Framework, manchmal länger als das Unternehmen. Entsprechend konservativ sollte die Wahl sein.

Option	Profil	Wann sinnvoll
Postgres (Hetzner, AWS RDS)	Universell, relational + JSON + Volltext + Vektor in einer Engine	Default für 90 % aller Business-Web-Apps
Neon	Serverless-Postgres, Branching pro Branch, EU-Region verfügbar	Schnelle Entwicklung, viele Preview-Umgebungen, kleine bis mittlere Produktion
Supabase	Managed Postgres mit Auth, Storage, Realtime in einem Paket	MVP-Phase, kleine Teams, schnelle Time-to-Market
Turso (SQLite Edge)	Edge-replizierte SQLite, sehr niedrige Latenz weltweit	Read-lastige Apps mit globaler Nutzerbasis und einfacher Datenmodellierung
Planetscale	Verteilte MySQL-kompatible Datenbank, gutes Branching-Modell	Sehr große Datenmengen, Teams mit MySQL-Hintergrund

Auf der ORM-Ebene ist Drizzle 2026 unser Default. Es liefert echtes SQL-Verständnis mit erstklassiger TypeScript-Inferenz, ohne Codegen-Schritt im Build und ohne den Overhead, den Prisma in größeren Schemas mitbringt. Prisma bleibt vertretbar für bestehende Projekte oder sehr große Datenmodelle mit etabliertem Migrations-Workflow.

Authentifizierung — der Layer, den niemand selbst bauen sollte

Auth ist der eine Bereich, in dem wir 2026 fast immer Managed-Lösungen empfehlen. Die Sicherheits-Anforderungen — Passwort-Hashing, Token-Rotation, OAuth, MFA, Session-Management, Audit-Log — sind hoch genug, dass eigene Implementierungen statistisch öfter Sicherheits-Lücken produzieren als sie nutzen.

• Clerk — sehr gute Developer-Erfahrung, fertige UI-Komponenten, breite Provider-Auswahl, eigene EU-Region — unser Default für Next.js-Projekte mit klarem Time-to-Market-Druck
• NextAuth / Auth.js — Open-Source-Klassiker, self-hosted, sehr flexibel, deutlich mehr Eigen-Konfiguration als Clerk — gut für Projekte mit eigenem Auth-Backend
• Better-Auth — junger TypeScript-First-Auth-Layer mit sehr guter Architektur, self-hosted, framework-agnostisch — erste Wahl für SvelteKit, Hono, Nuxt
• Lucia — minimaler, framework-agnostischer Session-Manager — passend, wenn das Team Auth vollständig selbst kontrollieren will, ohne fertige UI-Komponenten

Für DSGVO-sensible Workloads empfehlen wir Clerk in der EU-Region oder Self-Hosting mit Better-Auth bzw. NextAuth. Wer Auth-Daten in den USA verarbeitet, sollte das in der Datenschutz-Folgenabschätzung sauber dokumentieren.

Deployment — wo läuft die App tatsächlich

Hosting-Entscheidungen sind 2026 wirtschaftlich gewichtiger geworden, weil Serverless-Funktionen je nach Nutzungsmuster zwischen sehr günstig und sehr teuer schwanken. Vier Profile decken die meisten Mittelstands-Fälle ab.

• VercelSchnellste Time-to-Production für Next.js, integrierte Preview-Umgebungen, sehr gute Developer-Erfahrung. Kostengünstig bis mittlere Last, kann bei langen Funktion-Laufzeiten und großen Daten-Volumen teuer werden. Unser Default für Marketing-Seiten und für die meisten kleineren Apps.
• CloudflareWorkers, R2, D1, Pages — sehr starkes Edge-Modell, sehr aggressive Preise für statische Inhalte und CDN. Ideal für globale Apps mit hoher Lese-Last und für Hono-basierte Backends. Etwas mehr Eigen-Konfiguration nötig als bei Vercel.
• Fly.ioGlobales Container-Hosting mit guter Region-Steuerung, brauchbar für Apps, die nicht serverless-fähig sind und trotzdem global ausgespielt werden sollen. Preis-Leistung solide, Operations-Aufwand mittel.
• Hetzner + Coolify oder DokploySelf-Hosting auf EU-Servern, deutlich günstiger als alle Cloud-Hyperscaler ab mittlerem Traffic, voll DSGVO-konform. Verlangt eine Person mit Linux-Erfahrung und ein klares Backup- und Monitoring-Konzept. Unser Default für Hauptanwendungen größerer Reepa-Kundenprojekte.

In der Praxis kombinieren wir oft: Marketing-Seiten und Preview-Umgebungen auf Vercel, Hauptanwendung mit Datenbank auf Hetzner mit Coolify, Asset-Auslieferung über Cloudflare. Diese Kombination liefert gute Developer-Erfahrung, niedrige Betriebskosten und DSGVO-konforme Datenverarbeitung.

Bundle-Größe, Streaming, Edge — der Performance-Layer

Drei Konzepte haben sich 2026 als Standard etabliert und sollten in jeder seriösen Web-App-Architektur berücksichtigt werden. React Server Components verlagern Render-Arbeit auf den Server und reduzieren den JavaScript-Anteil im Browser dramatisch — eine Business-App, die in 2026 noch 800 KB JavaScript ausliefert, hat ein Architektur-Problem. Streaming-HTML liefert die Seite ab, sobald das Erste sinnvoll darstellbar ist, statt auf den langsamsten Datenbank-Aufruf zu warten — der gefühlte Performance-Gewinn ist erheblich. Edge-Rendering verlagert serverseitige Logik in CDN-nahe Knoten und reduziert die Latenz für globale Nutzer auf zweistellige Millisekunden. Diese drei Bausteine sind in Next.js 16, Nuxt 4 und SvelteKit 2 als first-class-Features verfügbar.

Reepa-Default-Stack 2026 — was wir tatsächlich bauen

Zum Abschluss der pragmatische Standard, mit dem wir bei Reepa Solutions die meisten neuen Kundenprojekte im Mittelstand starten. Er ist nicht der spannendste, sondern der mit dem besten Risiko-Profil bei drei bis fünf Jahren Lebensdauer.

Layer	Wahl	Warum
Frontend	React 19	Personalmarkt, Ökosystem, Stabilität
Meta-Framework	Next.js 16	Server Components, Cache Components, Vercel-Integration
Styling	Tailwind 4 + shadcn/ui	Schnell, konsistent, voller Code-Besitz
Sprache	TypeScript end-to-end	Typ-Sicherheit zwischen Frontend, Backend und Datenbank
Datenbank	Postgres (Hetzner oder Neon)	Universell, EU-Region, JSON + Volltext + Vektor in einer Engine
ORM	Drizzle	Typ-Inferenz, kein Codegen, SQL-Nähe
Auth	Clerk oder Better-Auth	Managed Security, EU-Region oder voll self-hosted
Hosting	Vercel + Hetzner + Cloudflare	Marketing auf Vercel, Hauptanwendung auf Hetzner, Assets über Cloudflare
Test	Vitest + Playwright	Schnelle Unit-Tests, robuste End-to-End-Tests

Dieser Stack ist bewusst konservativ. Er gewinnt keinen Innovations-Preis, aber er liefert vorhersehbare Wartungs-Kosten, einen großen Personalmarkt und niedrige technische Risiken über mehrere Jahre. Für Spezialfälle — sehr globale Apps, Performance-Frontends, datenintensive Dashboards — weichen wir gezielt ab. Wer eine Web-App im B2B-Mittelstand baut, fährt mit dieser Kombination in 80 Prozent der Fälle richtig. Vertiefende Hinweise zur Schnittstellen-Architektur stehen im Cluster REST vs. GraphQL; wer das Ganze für eine SaaS-Plattform skaliert, findet im SaaS-Aufbau-Leitfaden die wirtschaftliche Seite dazu.

Häufige Fragen