Frameworks: Werkzeug, Ballast oder einfach zu viel?
React, Vue, Angular, Svelte – überall. 2026 kommt kaum ein Projekt drumherum. Trotzdem werden die Seiten nicht schlanker. Im Gegenteil: Die Bundles wachsen, das Frontend wird träge. Wartung? Dauert oft länger als der Launch.
Die Idee: Alles im Browser laufen lassen, dann ist es "modern". In der Realität: Mobile Geräte haben zu tun, Suchmaschinen klettern durch halbgaren Client-Output, und beim nächsten Major-Update kracht die Build-Pipeline. Wer schon mal eine mittlere React-App auf Version 20 gehoben hat, erkennt das Drama. Viel Aufwand, wenig Fortschritt.
Minimalismus gewinnt: JS nur da, wo’s Sinn ergibt
Eine goldene Regel gibt es nicht. Aber weniger JavaScript hilft fast immer. Das heißt:
- Kein Framework für Kleinkram.
- Interaktivität gezielt einsetzen, nicht überall.
- Serverseitiges Rendering als Basis – für Speed und Übersicht.
Viele erfahrene Entwickler drehen das Rad zurück. Progressive Enhancement, einzelne Widgets hydrieren, Server-Output als Default. Wer den JS-Ballast klein hält, hat mehr Kontrolle und muss weniger nachziehen, wenn die nächste Dependency schreit.
Serverseitiges Rendering: Totgesagt, läuft aber besser denn je
SSR ist nicht retro, sondern pragmatisch. Inhalte serverseitig rendern heißt: Sofort sichtbare Seiten, weniger JS im ersten Rutsch. Wenn dann noch Interaktivität gebraucht wird, kommt JavaScript ins Spiel. Vorteil: Time-to-Interactive sinkt, Ressourcenverbrauch auch, SEO und Barrierefreiheit danken es.
Next.js, Nuxt, Remix – klar, auch die setzen auf SSR. Aber oft reicht ein klassisches PHP-Setup mit ein bisschen JS. Siehe auch: Back to Basics: Klassische PHP-Architektur 2026 – oft der pragmatischere Weg.
Große Frameworks, große Probleme – bekannte Fallen aus der Praxis
- 300 KB Bundle? Kein Problem, aber der First-Paint kommt dann halt auch erst nach gefühlten Ewigkeiten.
- Abhängigkeiten wachsen schneller als der eigene Bart. Irgendwann verliert jeder die Übersicht.
- State-Management: Klingt nach Kontrolle, bringt oft nur mehr Komplexität.
- Releases im Monatsrhythmus – und jedes Mal läuft was nicht mehr.
Viele kleine und mittlere Sites profitieren eher von weniger Framework. Wer auf Serverlogik plus ein paar unabhängige JS-Snippets setzt, hält Projekte flexibel und die Laune oben.
30 Jahre Webentwicklung: Mein Blick auf das Thema
Frameworks können Geschwindigkeit bringen, klar. Aber sie ziehen Komplexität nach. In Agenturen mit 5–10 Leuten reicht ein Update-Feuerwerk, und schon steht die Entwicklung tagelang still. Einzelkämpfer haben eh keine Lust, sich monatlich durch neue Doku zu kämpfen.
Was sich bewährt:
- Server-Rendering (PHP, Node.js) als stabile Grundlage
- Minimaler JS-Einsatz, nur wo’s wirklich gebraucht wird
- Kein globales State-Management, sondern kleine, abgegrenzte Komponenten
Das Ergebnis: Ladezeiten runter, weniger Pflegeaufwand, SEO und Barrierefreiheit im Griff. Klingt altmodisch, aber funktioniert auch 2026 deutlich besser als das JS-Karussell.
Praxis: Hydration statt Komplett-Frontend – echtes Beispiel
Kundenprojekt, echtes Problem: React-Single-Page-App, 400 KB Bundle, Time-to-Interactive bei 5 Sekunden. Umstellung auf SSR, gezielte Hydration nur für Such- und Filter-Widgets. Ergebnis: 70 KB JavaScript, TTI unter 1 Sekunde (Chrome DevTools), Hosting günstiger, Wartung weniger nervig.
Fazit: Kleine Frameworks, große Wirkung – aber nur gezielt
Frontend-Fatigue bleibt. Wer 2026 auf Performance, Übersicht und einfache Updates setzt, schraubt an der JS-Menge. Server-Rendering, kleine Bundles, gezieltes Hydrieren – das spart Zeit, Nerven und Hosting-Kosten. Für Agenturen wie Selbstständige.
Zurück zu Standards, dazu ein paar leichte Tools. Kein Rückschritt, sondern pragmatisch. Wer mehr Praxis will: Web-Performance 2026: AI, Edge und Frameworks im Alltag – was wirklich hilft.
bye
mo