Nicht veraltet, weil sie schlecht waren – sondern weil es heute bessere Antworten gibt
Die Webentwicklung bewegt sich in Zyklen. Was vor fünf Jahren Best Practice war, wird heute von Alternativen abgelöst, die grundlegend anders denken. Das bedeutet nicht, dass die alten Ansätze nicht funktionieren – sie tun es oft noch. Aber sie lösen Probleme, die in ihrer ursprünglichen Form gar nicht mehr existieren, oder sie erzeugen Komplexität, die heute vermeidbar ist.
Diese Liste ist kein Nachruf. Es ist eine Bestandsaufnahme: Welche Konzepte haben ihren Zenit überschritten, und was ist an ihre Stelle getreten?
1. REST als Default-API-Architektur
REST war über ein Jahrzehnt der unbestrittene Standard für Web-APIs. Endpunkte, HTTP-Verben, JSON – das Muster ist so tief verankert, dass viele Teams gar nicht mehr hinterfragen, ob REST die richtige Wahl ist.
Das Problem ist nicht REST selbst. Das Problem ist, dass REST für die häufigsten Anwendungsfälle 2026 unnötig viel Zeremonie erzeugt.
Was sich geändert hat:
- Server Actions und Server Components (Astro, Next.js, SolidStart) eliminieren die API-Schicht komplett. Formulare und Datenmutationen werden direkt als Serverfunktionen geschrieben – kein Endpunkt, kein Fetch, kein Serialisieren.
- tRPC liefert Ende-zu-Ende-Typsicherheit zwischen Client und Server. Kein OpenAPI-Schema, keine Code-Generierung, keine Versionierung. Der Server-Code ist der Vertrag.
- GraphQL hat für komplexe Datenmodelle mit vielen Konsumenten weiterhin seine Berechtigung, ersetzt REST aber eher in Richtung Federation und API-Gateways.
REST bleibt relevant für öffentliche APIs, die von externen Konsumenten genutzt werden. Für die interne Kommunikation zwischen Frontend und Backend einer Anwendung ist es 2026 meistens die umständlichere Lösung.
Mehr dazu: TanStack Start und Ende-zu-Ende-Typsicherheit, Ultra-performante Web-APIs mit Hono
2. Single Page Applications als Standardarchitektur
Die SPA-Ära hat das Web transformiert. React, Angular, Vue – ganze Generationen von Entwicklern haben gelernt, dass eine Webanwendung bedeutet: JavaScript lädt, rendert, routet, fetcht. Alles im Browser.
Das Ergebnis: Anwendungen, die 500 KB JavaScript ausliefern, um eine Produktliste anzuzeigen. Ladezeiten, die auf mobilen Geräten spürbar sind. SEO-Probleme, die mit SSR-Workarounds geflickt werden. Hydration-Kosten, die das negieren, was Server-Rendering an Performance bringt.
Was sich geändert hat:
- Islands Architecture (Astro, Fresh) rendert standardmäßig auf dem Server. Nur die Teile der Seite, die tatsächlich interaktiv sein müssen, laden JavaScript. Der Rest ist statisches HTML.
- Partial Hydration und Resumability (Qwik) gehen noch weiter: JavaScript wird erst geladen, wenn der User damit interagiert – nicht beim Seitenaufruf.
- HTMX zeigt, dass viele sogenannte “interaktive” Features (Formulare, Filter, Tabs, Modals) kein clientseitiges Framework brauchen. HTML-Attribute reichen.
Die SPA ist nicht tot. Für echte Anwendungen – Editoren, Dashboards mit Echtzeit-Updates, komplexe Formulare mit Abhängigkeiten – bleibt sie das richtige Modell. Aber als Default für jedes Webprojekt hat sie ausgedient.
Mehr dazu: HTMX: Wann der Verzicht auf React die bessere Wahl ist, Moderne Webentwicklung mit Astro & Svelte
3. Webpack als Build-Tool
Webpack war jahrelang das Rückgrat der Frontend-Toolchain. Es hat Module im Browser erst möglich gemacht, als es noch keinen nativen Support dafür gab. Aber diese Zeit ist vorbei.
Webpack-Konfigurationen sind notorisch komplex. Loader-Ketten, Plugin-Konflikte, Rebuild-Zeiten von mehreren Sekunden bei größeren Projekten – das war der Preis für Flexibilität. Heute zahlt den fast niemand mehr freiwillig.
Was sich geändert hat:
- Vite nutzt native ES-Module im Entwicklungsmodus. Kein Bundling beim Dev-Server, Hot Module Replacement in Millisekunden. Für Produktion wird mit Rollup gebundelt – mit sinnvollen Defaults.
- Bun geht noch einen Schritt weiter: Runtime, Paketmanager und Bundler in einem Tool. Native Performance durch Zig, kompatibel mit dem Node-Ökosystem.
- Native ESM im Browser macht Bundling für kleinere Projekte optional. Import Maps erlauben es, Dependencies ohne Build-Step zu laden.
Webpack wird in Legacy-Projekten noch Jahre weiterlaufen. Für neue Projekte gibt es keinen Grund mehr, es zu wählen.
Mehr dazu: Bun statt Node.js: Ein praktischer Einstieg, Weniger ist schneller: Der Trend zu integrierten Ökosystemen
4. CSS-in-JS als Styling-Lösung
styled-components, Emotion, JSS – die Idee, CSS in JavaScript zu schreiben, war eine Reaktion auf reale Probleme: Scope-Konflikte, fehlende Dynamik, keine Kopplung an Komponentenlogik.
Aber CSS-in-JS löst diese Probleme mit erheblichen Kosten: Runtime-Overhead, größere Bundles, erschwertes Caching, Server-Side-Rendering-Komplexität. Und die Probleme, die es löst, existieren in der Form nicht mehr.
Was sich geändert hat:
- CSS Nesting, Container Queries,
@scope,@layer– natives CSS hat in den letzten zwei Jahren mehr Fortschritte gemacht als in den zehn Jahren davor. Scope-Probleme lassen sich nativ lösen. - Tailwind CSS eliminiert die Naming-Problematik komplett. Utility Classes sind per Definition gescopet, weil sie atomar sind.
- CSS Modules und Astro-Scoping bieten komponentenbezogenes CSS ohne Runtime-Kosten.
Wer heute CSS-in-JS in einem neuen Projekt einsetzt, optimiert für ein Problem, das die Plattform selbst bereits gelöst hat.
Mehr dazu: CSS-in-JS: Anti-Patterns und wann es sich nicht lohnt, Warum ich doch noch Fan von Tailwind wurde
5. Node.js als einzige Server-Runtime
Node.js hat JavaScript auf den Server gebracht und ein ganzes Ökosystem ermöglicht. Aber die Annahme, dass der Server automatisch in JavaScript geschrieben wird, weil das Frontend es auch ist – diese Logik trägt nicht mehr.
Was sich geändert hat:
- Edge Runtimes (Cloudflare Workers, Deno Deploy, Vercel Edge) führen Code näher am User aus. Sie nutzen V8 Isolates statt voller Node-Prozesse – schnellere Cold Starts, geringerer Speicherverbrauch, globale Verteilung.
- Bun ersetzt Node.js als Runtime mit deutlich höherer Performance bei I/O-Operationen und nativem TypeScript-Support.
- Rust und Go sind für CPU-intensive Aufgaben, Datenverarbeitung und Systemlogik die bessere Wahl. Nicht als Ersatz für alles, aber für die Teile, wo JavaScript an seine Grenzen stößt.
- WebAssembly Server-Side (Spin, wasmCloud) ermöglicht es, kompilierte Module in Microsekunden zu starten – Größenordnungen schneller als Container.
Node.js bleibt ein gutes Tool für viele Aufgaben. Aber die automatische Gleichung “Webprojekt = Node.js” ist überholt.
Mehr dazu: JavaScript, npm & Node.js – Allzweckwaffe vs. veraltete Hypothek, Bun unter der Haube
6. Docker-Container für jede Webanwendung
Docker hat das Deployment revolutioniert. Reproduzierbare Umgebungen, Infrastructure as Code, Microservice-Architekturen – alles gebaut auf Containern. Aber für viele Webanwendungen ist Docker 2026 Overhead, den es nicht braucht.
Was sich geändert hat:
- Edge Deployment (Cloudflare Workers, Deno Deploy) braucht keine Container. Code wird als V8 Isolate ausgeführt – kein OS, kein Dateisystem, keine Container-Runtime. Cold Starts unter 5 Millisekunden statt mehrerer Sekunden.
- Serverless Functions (AWS Lambda, Vercel Functions) abstrahieren die Infrastruktur komplett. Kein Dockerfile, kein Image, kein Registry.
- WASM-Container (Spin, wasmCloud) bieten eine leichtgewichtige Alternative für Workloads, die mehr brauchen als Edge Functions, aber weniger als einen vollen Container.
- Static Site Generators mit Pre-Rendering eliminieren den Server komplett. Eine Astro-Site braucht nur ein CDN.
Docker bleibt unverzichtbar für komplexe Backend-Systeme, Datenbanken und Microservice-Architekturen. Für die Auslieferung einer Webanwendung ist es in den meisten Fällen nicht mehr der richtige Ansatz.
Mehr dazu: Container oder WebAssembly? Eine Architekturentscheidung, Cloudflare Workers und Pages – Best Practices
7. CommonJS als Modulsystem
require() und module.exports – das Fundament des Node.js-Ökosystems. Tausende Packages, jahrelang der einzige Weg, Module in JavaScript zu nutzen. Aber CommonJS war immer ein Workaround für eine Lücke in der Sprache, die inzwischen geschlossen ist.
Was sich geändert hat:
- ES Modules sind der offizielle JavaScript-Standard.
import/exportfunktioniert in allen Browsern, in Node.js, Deno, Bun und auf Edge Runtimes. - Tree Shaking funktioniert nur mit ESM. CommonJS-Module können nicht statisch analysiert werden – tote Code-Pfade bleiben im Bundle.
- Edge Runtimes unterstützen kein CommonJS. Cloudflare Workers, Deno Deploy und Vercel Edge setzen ESM voraus. Wer CommonJS nutzt, muss transpilieren.
- Dual Publishing (CJS + ESM) erzeugt Komplexität in Package-Konfigurationen, die mit reinem ESM entfällt.
Die Migration ist nicht trivial – besonders bei Packages mit tiefen CommonJS-Abhängigkeiten. Aber für neuen Code gibt es keinen Grund mehr, CommonJS zu schreiben.
Mehr dazu: Edge Computing und JavaScript-Module: Warum ESM die Zukunft gehört
8. Redux und komplexe State-Management-Libraries
Redux hat 2015 ein echtes Problem gelöst: Zustandsverwaltung in großen React-Anwendungen war chaotisch. Actions, Reducers, ein zentraler Store – das brachte Ordnung. Aber es brachte auch Boilerplate, indirekte Datenflüsse und eine Lernkurve, die für die meisten Anwendungen unverhältnismäßig war.
Was sich geändert hat:
- Signals (Solid, Preact, Angular, Svelte 5 Runes) bieten fine-grained Reactivity ohne zentralen Store. Zustand wird dort definiert, wo er gebraucht wird. Updates propagieren automatisch, ohne dass Komponenten-Bäume neu gerendert werden.
- Server State Libraries (TanStack Query, SWR) haben gezeigt, dass der Großteil dessen, was in Redux-Stores landete, eigentlich Server-State war – gecachte API-Responses mit Invalidierung und Refetching.
- Zustand und Jotai bieten für die Fälle, in denen tatsächlich globaler Client-State nötig ist, minimale APIs ohne die Zeremonie von Redux.
Redux Toolkit hat Redux deutlich vereinfacht. Aber das Grundproblem bleibt: Die meisten Anwendungen brauchen keinen zentralen Store. Sie brauchen reaktive Primitiven und intelligentes Server-State-Management.
Mehr dazu: Svelte kompakt – Reaktivität, Stores und Komponenten-Architektur
9. Manuelle API-Dokumentation und Versionierung
Swagger-Dateien pflegen, OpenAPI-Specs von Hand aktualisieren, Postman-Collections synchron halten – das war jahrelang notwendig, weil es keine bessere Option gab. Die API-Dokumentation lebte getrennt vom Code und war deshalb permanent veraltet.
Was sich geändert hat:
- tRPC eliminiert Dokumentation als Konzept. Der Server-Code definiert die Typen, der Client konsumiert sie direkt. Ändert sich eine Funktion, bricht der Client-Build – nicht die Dokumentation.
- GraphQL Introspection generiert Dokumentation automatisch aus dem Schema. Tools wie GraphiQL und Apollo Studio machen separate Docs überflüssig.
- Zod und TypeBox validieren und dokumentieren gleichzeitig. Das Schema ist die Dokumentation und die Validierung in einem.
- Contract Testing (Pact) verifiziert, dass API-Konsumenten und -Provider kompatibel sind – automatisiert, nicht durch manuelles Lesen von Docs.
Für öffentliche APIs bleibt gute Dokumentation essenziell. Für interne APIs ist der Trend klar: Der Code selbst muss der Single Source of Truth sein, nicht ein separates Dokument.
10. JavaScript als einzige Browser-Sprache
Das ist der Paradigmenwechsel, der am längsten braucht – aber er ist im Gang. JavaScript war drei Jahrzehnte lang die einzige Sprache, die nativ im Browser lief. WebAssembly ändert das fundamental.
Was sich geändert hat:
- Rust-Frameworks wie Leptos, Yew und Dioxus bauen vollständige Web-UIs, die zu WebAssembly kompilieren. Reaktive Systeme, Server-Side Rendering, Routing – alles in Rust, mit der Performance und Typsicherheit, die die Sprache mitbringt.
- PGlite bringt eine vollständige Postgres-Instanz als WASM in den Browser. 3 MB gzipped, mit Extensions wie
pgvectorfür Vektor-Suche. - Figma, Google Earth, AutoCAD – produktive Anwendungen, die bereits heute auf WASM setzen, nicht als Experiment, sondern in Produktion.
- WASI erweitert WebAssembly über den Browser hinaus. Kompilierte Module laufen auf Edge, Server und IoT-Devices – ein Binary, überall.
JavaScript wird nicht verschwinden. Aber die Annahme, dass alles im Browser in JavaScript geschrieben sein muss, ist 2026 keine Tatsache mehr, sondern eine Gewohnheit.
Mehr dazu: Rust im Browser: Leptos, Yew und Dioxus im Vergleich, Container oder WebAssembly?
Was diese Liste nicht sagt
Keines dieser Paradigmen ist “schlecht”. REST hat APIs demokratisiert. SPAs haben interaktive Web-Experiences erst möglich gemacht. Webpack hat das moderne Frontend-Tooling begründet. Docker hat Deployment vorhersagbar gemacht.
Aber Technologie entwickelt sich weiter, und die Kosten-Nutzen-Rechnung verschiebt sich. Was sich geändert hat, ist nicht die Qualität der alten Lösungen – sondern die Existenz besserer Alternativen, die weniger Kompromisse erfordern.
Die eigentliche Frage für jedes Team ist nicht “Nutzen wir noch X?” – sondern “Wählen wir X, weil es die beste Option ist, oder weil es die vertrauteste ist?”