Was im Frontend passiert ist, während du nicht hingeschaut hast

kciter1 · 2026-07-20T02:12:58+09:00

Ein Text für Entwickler, die das Frontend etwa 2008 verlassen haben, der die Veränderungen der vergangenen 20 Jahre erklärt Die zentrale These: Alle Tools sind Narbengewebe, das auf realen Problemen entstanden ist, und die Lösung jeder Schicht hat die Probleme der nächsten Schicht erzeugt und aufeinandergetürmt Im gesamten Text dient ein einzelnes ``` als Anschauungsobjekt, um nachzuverfolgen, wie sich Buttons in jeder Epoche verändert haben Layer I — jQuery (2006–2010) Ausgangspunkt war der Wunsch, nur Teile der Seite zu ändern, ohne die gesamte Seite neu zu laden jQuery beseitigte Unterschiede zwischen Browsern und popularisierte AJAX, erzeugte aber das Problem, dass Daten sowohl in JS-Variablen als auch auf dem Bildschirm existierten und Entwickler sie selbst synchron halten mussten Diese manuelle DOM-Manipulation ist die „Erbsünde“, die alle späteren Schichten zu lösen versuchen Layer II — Frameworks (2010–2015) Deklarative UI: Statt den Ablauf zur Aktualisierung des Bildschirms zu beschreiben, beschreibt man das Aussehen des Bildschirms anhand der Daten, und das Framework übernimmt die Aktualisierung React prägte die Ära mit Komponenten + JSX + Virtual DOM, gefolgt von Vue/Angular/Svelte/Solid Heute nähern sich alle Frameworks dem Signal-Konzept an, bei dem Abhängigkeiten verfolgt und nur die nötigen Stellen aktualisiert werden Es gibt auch ein Lager, das zu dem Ansatz zurückkehrt, HTML vom Server zu senden, etwa mit htmx, Alpine.js und Hotwire Layer III — Build (2012–2018) Da JS kein Modulsystem hatte, konkurrierten CommonJS und ES Modules, und für die Kompatibilität mit älteren Browsern wurden Babel-Transpilation und webpack-Bundling nötig Der Build umfasst Minify, Tree-Shaking, Code-Splitting und die Erzeugung von Source Maps Der Preis dafür war node_modules; selbst ein leeres Starter-Projekt installiert rund 250.000 Dateien Layer IV — Tooling-Wettbewerb (2018–2024) Eine Ära, in der langsame Builds und komplexe webpack-Konfigurationen durch Neuschreibungen in Go/Rust gelöst wurden esbuild (Go) machte Bundling 10–100-mal schneller, und SWC (Rust) ersetzt Babel Vite hat sich als Standardtool etabliert, der Production-Bundler wird auf das Rust-basierte Rolldown umgestellt, und der zugehörige Stack wird unter VoidZero (kürzlich von Cloudflare übernommen) zusammengeführt Auch Paketmanager wie pnpm und Bun folgen derselben Entwicklung Layer V — Die Rückkehr des Server-Renderings (2014–2026) Bei SPAs sendet der Server nur ein leeres div, weshalb beim ersten Laden ein leerer Bildschirm erscheint und Suchmaschinen ebenfalls nur eine leere Seite sehen Die Lösung besteht darin, HTML wieder auf dem Server zu rendern — eine Rückkehr zur Methode von 2008 Es entstanden SSR (Rendering pro Anfrage), SSG (Vorab-Rendering beim Build) und ISR (automatisch aktualisiertes SSG); Meta-Frameworks wie Next.js, Astro, SvelteKit und Nuxt übernehmen das Die Kosten der Hydration, also das erneute Aktivieren des Server-HTMLs im Browser, wurden zum neuen Problem; Islands (Astro), Resumability (Qwik) und React Server Components entstanden als Wege, Hydration zu reduzieren Layer VI — Engineering-Tools (2015–2026) TypeScript sorgte mit seinem Typsystem für sichere Refactorings und wurde de facto zum Standard Während Tailwind mit Utility-Klassen das Styling anführt, hat sich auch natives CSS mit Nesting, Variablen und Container Queries weiterentwickelt, wodurch bestehendes Tooling weniger nötig wird shadcn/ui etablierte den Ansatz, Komponenten nicht zu installieren, sondern den Source Code zu kopieren und zu besitzen; TanStack Query, Zustand, Zod, Vitest und Playwright bilden den Grundwortschatz einer App im Jahr 2026 Layer VII — Deployment (2015–2026) Statt Upload per FTP verbindet man ein Git-Repository mit Vercel/Netlify/Cloudflare; bei jedem Push wird automatisch gebaut und deployt, und für jeden PR entsteht eine Live-Preview-URL Serverless Functions und Edge (Code-Ausführung in Hunderten von Rechenzentren nahe beim Nutzer) haben sich als Konzepte etabliert Layer VIII — AI (2023–2026) Wenn man v0, Lovable oder Bolt in natürlicher Sprache beschreibt, was man will, entsteht ein funktionierendes Frontend; Cursor, Claude Code und Copilot schreiben den Code stellvertretend Dadurch können auch Backend- oder System-Engineers in nur einem Tag ein Frontend bauen, wodurch die Grenzen zwischen Engineering-Bereichen verschwimmen Der erzeugte Code setzt allerdings Wissen über die oben genannten acht Schichten voraus; diese Lücke zu schließen, ist das Ziel des Textes Bedrock — Fazit Die Richtung an der Front im Jahr 2026 lautet: HTML auf dem Server rendern, fast kein JS ausliefern und die Webplattform nutzen Das Fazit lautet, dass die Branche nach 20 Jahren in einem großen Kreis an einem Punkt angekommen ist, der den früher per FTP hochgeladenen Dateien ähnelt

Ein Text für Entwickler, die das Frontend etwa 2008 verlassen haben, der die Veränderungen der vergangenen 20 Jahre erklärt
Die zentrale These: Alle Tools sind Narbengewebe, das auf realen Problemen entstanden ist, und die Lösung jeder Schicht hat die Probleme der nächsten Schicht erzeugt und aufeinandergetürmt
Im gesamten Text dient ein einzelnes `<button>`` als Anschauungsobjekt, um nachzuverfolgen, wie sich Buttons in jeder Epoche verändert haben

Layer I — jQuery (2006–2010)
- Ausgangspunkt war der Wunsch, nur Teile der Seite zu ändern, ohne die gesamte Seite neu zu laden
- jQuery beseitigte Unterschiede zwischen Browsern und popularisierte AJAX, erzeugte aber das Problem, dass Daten sowohl in JS-Variablen als auch auf dem Bildschirm existierten und Entwickler sie selbst synchron halten mussten
- Diese manuelle DOM-Manipulation ist die „Erbsünde“, die alle späteren Schichten zu lösen versuchen
Layer II — Frameworks (2010–2015)
- Deklarative UI: Statt den Ablauf zur Aktualisierung des Bildschirms zu beschreiben, beschreibt man das Aussehen des Bildschirms anhand der Daten, und das Framework übernimmt die Aktualisierung
- React prägte die Ära mit Komponenten + JSX + Virtual DOM, gefolgt von Vue/Angular/Svelte/Solid
- Heute nähern sich alle Frameworks dem Signal-Konzept an, bei dem Abhängigkeiten verfolgt und nur die nötigen Stellen aktualisiert werden
- Es gibt auch ein Lager, das zu dem Ansatz zurückkehrt, HTML vom Server zu senden, etwa mit htmx, Alpine.js und Hotwire
Layer III — Build (2012–2018)
- Da JS kein Modulsystem hatte, konkurrierten CommonJS und ES Modules, und für die Kompatibilität mit älteren Browsern wurden Babel-Transpilation und webpack-Bundling nötig
- Der Build umfasst Minify, Tree-Shaking, Code-Splitting und die Erzeugung von Source Maps
- Der Preis dafür war node_modules; selbst ein leeres Starter-Projekt installiert rund 250.000 Dateien
Layer IV — Tooling-Wettbewerb (2018–2024)
- Eine Ära, in der langsame Builds und komplexe webpack-Konfigurationen durch Neuschreibungen in Go/Rust gelöst wurden
- esbuild (Go) machte Bundling 10–100-mal schneller, und SWC (Rust) ersetzt Babel
- Vite hat sich als Standardtool etabliert, der Production-Bundler wird auf das Rust-basierte Rolldown umgestellt, und der zugehörige Stack wird unter VoidZero (kürzlich von Cloudflare übernommen) zusammengeführt
- Auch Paketmanager wie pnpm und Bun folgen derselben Entwicklung
Layer V — Die Rückkehr des Server-Renderings (2014–2026)
- Bei SPAs sendet der Server nur ein leeres div, weshalb beim ersten Laden ein leerer Bildschirm erscheint und Suchmaschinen ebenfalls nur eine leere Seite sehen
- Die Lösung besteht darin, HTML wieder auf dem Server zu rendern — eine Rückkehr zur Methode von 2008
- Es entstanden SSR (Rendering pro Anfrage), SSG (Vorab-Rendering beim Build) und ISR (automatisch aktualisiertes SSG); Meta-Frameworks wie Next.js, Astro, SvelteKit und Nuxt übernehmen das
- Die Kosten der Hydration, also das erneute Aktivieren des Server-HTMLs im Browser, wurden zum neuen Problem; Islands (Astro), Resumability (Qwik) und React Server Components entstanden als Wege, Hydration zu reduzieren
Layer VI — Engineering-Tools (2015–2026)
- TypeScript sorgte mit seinem Typsystem für sichere Refactorings und wurde de facto zum Standard
- Während Tailwind mit Utility-Klassen das Styling anführt, hat sich auch natives CSS mit Nesting, Variablen und Container Queries weiterentwickelt, wodurch bestehendes Tooling weniger nötig wird
- shadcn/ui etablierte den Ansatz, Komponenten nicht zu installieren, sondern den Source Code zu kopieren und zu besitzen; TanStack Query, Zustand, Zod, Vitest und Playwright bilden den Grundwortschatz einer App im Jahr 2026
Layer VII — Deployment (2015–2026)
- Statt Upload per FTP verbindet man ein Git-Repository mit Vercel/Netlify/Cloudflare; bei jedem Push wird automatisch gebaut und deployt, und für jeden PR entsteht eine Live-Preview-URL
- Serverless Functions und Edge (Code-Ausführung in Hunderten von Rechenzentren nahe beim Nutzer) haben sich als Konzepte etabliert
Layer VIII — AI (2023–2026)
- Wenn man v0, Lovable oder Bolt in natürlicher Sprache beschreibt, was man will, entsteht ein funktionierendes Frontend; Cursor, Claude Code und Copilot schreiben den Code stellvertretend
- Dadurch können auch Backend- oder System-Engineers in nur einem Tag ein Frontend bauen, wodurch die Grenzen zwischen Engineering-Bereichen verschwimmen
- Der erzeugte Code setzt allerdings Wissen über die oben genannten acht Schichten voraus; diese Lücke zu schließen, ist das Ziel des Textes
Bedrock — Fazit
- Die Richtung an der Front im Jahr 2026 lautet: HTML auf dem Server rendern, fast kein JS ausliefern und die Webplattform nutzen
- Das Fazit lautet, dass die Branche nach 20 Jahren in einem großen Kreis an einem Punkt angekommen ist, der den früher per FTP hochgeladenen Dateien ähnelt

Was im Frontend passiert ist, während du nicht hingeschaut hast

Verwandte Beiträge

4 Kommentare