Frontend-Frameworks – Ein tiefer Einblick
Vorwort
Du hast bereits die Grundlagen von HTML, CSS und JavaScript gelernt und kannst einfache Webseiten erstellen. Doch je komplexer die Funktionen einer Webseite werden, desto deutlicher wird: Mit nativem JavaScript wird der Code schwer zu warten – eine Änderung an einer Stelle zieht viele weitere Änderungen nach sich, und bei der Zusammenarbeit im Team kommt es häufig zu Konflikten.
Genau deshalb brauchen wir Frontend-Frameworks – sie machen den Code strukturierter, wartbarer und die Entwicklung effizienter. Beim Vibecoding schreibt die KI den Großteil des Codes für dich. Aber du solltest zumindest den Code-Stil verschiedener Frameworks lesen und ihre Vor- und Nachteile kennen, damit die KI den am besten geeigneten Tech-Stack für dich auswählen kann.
Nach der Lektüre dieses Kapitels kannst du:
- Verstehen, warum sich Frontend-Technologien ständig weiterentwickeln müssen
- Die Besonderheiten von Vue, React, Svelte und Angular kennen
- Kernkonzepte wie „Datengetriebenheit" und „Komponentisierung" verstehen
- Das passende Framework für dein Projekt auswählen
Was lernst du in diesem Artikel?
| Kapitel | Inhalt | Was du danach kannst |
|---|---|---|
| Kapitel 1 | Warum die Frontend-Evolution wichtig ist | Verstehen, welche Probleme die technologische Evolution löst |
| Kapitel 2 | Die Ära der statischen Webseiten | Die frühesten Webentwicklungsmethoden kennenlernen |
| Kapitel 3 | Die jQuery-Ära | Die Schwachstellen des „imperativen" Programmierens verstehen |
| Kapitel 4 | Die Vue/React-Ära | Das „deklarative" und „datengetriebene" Denken beherrschen |
| Kapitel 5 | Rendering-Strategien | Die Unterschiede und Anwendungsfälle von CSR, SSR und SSG kennen |
| Kapitel 6 | Engineering-Tools | Die Rolle von Build-Tools wie Webpack und Vite verstehen |
Jedes Kapitel beginnt mit der Frage „Warum brauchen wir diese Technologie?", damit du die Logik hinter der technologischen Evolution verstehst.
1. Warum die Frontend-Evolutionsgeschichte wichtig ist
🤔 Kernfrage
Warum werden Webseiten immer komplexer? Warum müssen sich Frontend-Technologien ständig weiterentwickeln? Diese Frage führt dich durch die technologische Entwicklung von einfachen Webseiten hin zu modernen Webanwendungen.
1.1 Vom „elektronischen Poster" zur „Desktop-Anwendung"
Stell dir ein Plakat vor, das du auf der Straße siehst:
- ✅ Es hat Inhalte (Text, Bilder)
- ✅ Es hat ein Design (Farben, Layout)
- ❌ Aber wenn du mit ihm sprichst, antwortet es nicht
- ❌ Wenn du irgendwo draufklickst, passiert nichts
Die frühesten Webseiten waren genau solche „elektronischen Poster": nur lesbar, nicht veränderbar, mit festem Inhalt.
Moderne Webseiten sind völlig anders. Sie ähneln Desktop-Anwendungen (VS Code, Figma):
- ✅ Du kannst Dokumente bearbeiten, zeichnen, Spiele spielen
- ✅ Sie reagieren in Echtzeit auf jede deiner Aktionen
- ✅ Sie können sogar offline arbeiten
Der Hauptgrund für diesen Wandel: Die Funktionen von Webseiten werden immer komplexer und erfordern effizientere Technologien und Entwicklungsmethoden.
1.2 Eine Alltagsmetapher: Hausbau
Die Evolution der Frontend-Technologien gleicht der Entwicklung des Hausbaus:
| Ära | 🏠 Hausbau-Metapher | Tatsächliche Merkmale | Vor- und Nachteile |
|---|---|---|---|
| 2000er | Plakate aufhängen | Statische Webseiten, einfach HTML schreiben | ✅ Einfach ❌ Keine Interaktivität |
| 2010er | Handwerker manuell renovieren lassen | jQuery-Ära, jedes Element manuell bedienen | ✅ Interaktiv ❌ Chaotischer Code, schwer wartbar |
| 2020er | Mit Lego ein Haus bauen | Vue/React-Ära, komponentenbasierte Entwicklung | ✅ Effizient, wartbar ❌ Lernkurve |
💡 Was kannst du aus dieser Tabelle mitnehmen?
Phase 1 → Phase 2: Von „unbeweglich" zu „beweglich". Ein qualitativer Sprung – Webseiten werden interaktiv, aber auf Kosten von chaotischem Code.
Phase 2 → Phase 3: Von „funktionsfähig" zu „gut nutzbar". Komponentisierung macht Code wie Bausteine wiederverwendbar und steigert die Entwicklungseffizienz erheblich.
Kerngedanke: Technologische Evolution geschieht nicht „des Neuen wegen", sondern um die Schwachstellen der vorherigen Phase zu beheben.
2. Phase 1: Statische Webseiten und „Slicing" (2000er)
🤔 Kernfrage
Wie sahen die frühesten Webseiten aus? Warum brauchte man damals keine Frameworks? Nur wenn du die Grenzen dieser Phase verstehst, erkennst du die Notwendigkeit der späteren technologischen Evolution.
I. The Static Era
Web pages were just digital documents. The server sent HTML, and the browser rendered it. Want new content? Refresh the whole page.
<html>
<body>
<h1>Hello World</h1>
<p>Static content served by server.</p>
</body>
</html>2.1 Wie war diese Ära?
Entwicklungsmethode:
- Ein paar HTML-Dateien schreiben
- Etwas CSS und JavaScript einbetten
- Die Dateien direkt in den Browser ziehen, um das Ergebnis zu sehen
- Den Ordner auf den Server hochladen – Deployment abgeschlossen
Merkmale:
- ✅ Vorteile: Einfach und direkt, keine Lernkurve, schreiben und loslegen
- ❌ Nachteile: Keine komplexen Interaktionen möglich, Code wird bei zunehmender Menge schnell chaotisch
Projektstruktur damals
project/
├── index.html
├── login.html
├── css/
│ ├── bootstrap.css
│ └── custom.css
├── js/
│ ├── jquery.js
│ └── app.js
└── images/Aufgetretene Probleme:
- Globale Variablenverschmutzung: Alle Variablen im globalen Namensraum, überschreiben sich leicht gegenseitig
- Chaotisches Abhängigkeitsmanagement: JS-Dateien müssen in der richtigen Reihenfolge geladen werden, sonst gibt es Fehler
- Schwer wiederverwendbarer Code: Um eine Funktion wiederzuverwenden, bleibt nur Kopieren und Einfügen
2.2 Was ist „Slicing"?
Du hast vielleicht schon den Begriff „Slicing" gehört. Es war die Hauptaufgabe der frühen Frontend-Entwicklung:
Was ist Slicing?
Designer gestaltet die Seite in Photoshop → Frontend schneidet das Design in kleine Bilder → Mit HTML werden die Bilder zur Seite zusammengesetzt
Warum war das so langsam?
Für jedes kleine Bild auf der Webseite musste der Browser eine Netzwerkanfrage senden. Je mehr Anfragen, desto langsamer der Ladevorgang.
👇 Probier es selbst aus: Beobachte, wie sich Bildanfragen auf die Ladeleistung auswirken
💡 Sprites (CSS-Sprites)
Um die Anzahl der Anfragen zu reduzieren, entstand die „Sprite"-Technik: Viele kleine Bilder werden zu einem großen Bild zusammengefasst.
Der Vorteil: weniger Anfragen. Der Nachteil: Erstellung und Wartung sind aufwändig.
Die Lehre aus dieser Phase: Zu viele Anfragen sind der größte Feind der Performance.
3. Phase 2: Die jQuery-Ära – „Manuelles Steine schleppen" (2010er)
🤔 Kernfrage
Warum brauchte man jQuery? Welche Probleme hat es gelöst und welche neuen hat es gebracht? Nur wenn du die Grenzen von jQuery verstehst, erkennst du den Wert von Vue/React.
3.1 Warum brauchte man jQuery?
Mit zunehmender Komplexität der Webseiten traten die Probleme von nativem JavaScript zutage:
- ❌ Umständliche API: Selbst einfache Operationen erforderten viel Code
- ❌ Browserkompatibilität: Verschiedene Browser hatten unterschiedliche APIs, viel Kompatibilitätscode war nötig
- ❌ Schwache Selektoren: Elemente zu finden war mühsam
jQuery wurde geboren. Es machte JavaScript einfach:
// Natives JavaScript (umständlich)
const element = document.getElementById('title')
// jQuery (einfach)
const element = $('#title')3.2 Der jQuery-Ansatz: Die Seite selbst verändern
Der Kernansatz von jQuery ist imperativ: Du sagst dem Browser, „wie" er es tun soll.
// Das Titel-Element finden
$('#title').text('Neuer Titel')
// Den Button finden und deaktivieren
$('#submit-btn').attr('disabled', true)
// Die Liste finden und ein Element hinzufügen
$('ul').append('<li>Neues Element</li>')Das Problem: Du musst dir merken, welche Elemente auf der Seite sind, und bei jeder Datenänderung alle betroffenen Elemente manuell aktualisieren.
👇 Probier es selbst aus: Vergleiche jQuery mit dem datengetriebenen Ansatz
⚠️ Die Schwachstellen von jQuery
Stell dir vor, du baust einen Warenkorb:
// Nutzer klickt auf „In den Warenkorb"
function addToCart() {
cartCount++ // Daten ändern sich
// Du musst alle betroffenen Stellen manuell aktualisieren
$('#cart-count').text(cartCount) // Der rote Punkt oben rechts
$('#cart-page-count').text(cartCount) // Die Warenkorb-Seite
$('#checkout-price').text(calculatePrice()) // Der Bezahl-Button
// Wenn du eine Stelle vergisst, ist die Seite inkonsistent!
}Das ist der Preis des „manuellen Steine schleppens": fehleranfällig und schwer wartbar.
3.3 Der Aufstieg mobiler Geräte: Responsive Design entsteht
In dieser Phase gab es noch eine wichtige Veränderung: Smartphones und Tablets wurden populär.
Webseiten mussten sich an verschiedene Bildschirme anpassen. Das erforderte Responsive Layouts: Derselbe HTML/CSS-Code passt das Layout automatisch an die Bildschirmbreite an.
Der Kern des Responsive Layouts: Media Queries
/* Desktop-Bildschirm (größer als 640px) */
@media (min-width: 640px) {
.container {
display: flex;
}
}
/* Handy-Bildschirm (kleiner als 640px) */
@media (max-width: 640px) {
.container {
display: block;
}
}👇 Probier es selbst aus: Ändere die Browser-Breite und beobachte den Effekt des Responsive Layouts
💡 Responsive Design ist wie ein „intelligenter Bilderrahmen"
Stell dir vor, du betrachtest dasselbe Foto in verschiedenen Räumen:
- Im großen Wohnzimmer (Desktop-Bildschirm) kann das Foto größer sein, mit dekorativen Elementen daneben
- Im kleinen Schlafzimmer (Handy-Bildschirm) muss das Foto kleiner sein, die Dekorationen werden weggeräumt
Responsive Layouts sind wie ein „intelligenter Bilderrahmen", der die Darstellung automatisch an die Raumgröße anpasst.
4. Phase 3: Vom „manuellen Steine schleppen" zum „datengetriebenen" Ansatz (Vue/React)
🤔 Kernfrage
Warum brauchen wir Vue/React? Was ist der wesentliche Unterschied zu jQuery? Das Verständnis von „deklarativ" und „datengetrieben" ist der Schlüssel zur Beherrschung moderner Frontend-Frameworks.
4.1 Warum brauchen wir neue Frameworks?
Die Probleme der jQuery-Ära häuften sich:
- Code wird bei zunehmender Menge chaotisch: Überall DOM-Operationen, schwer wartbar
- Fehleranfällig: Eine vergessene Aktualisierung macht die Seite inkonsistent
- Schwierige Zusammenarbeit: Mehrere Personen bearbeiten dieselbe Datei, häufige Konflikte
Der Kernansatz von Vue / React: Nur die Daten ändern, die Seite aktualisiert sich automatisch.
4.2 Der Vue/React-Ansatz: Deklarative UI
jQuery (imperativ):
// Du sagst dem Browser jeden Schritt, den er tun soll
$('#title').text('Neuer Titel')
$('#title').css('color', 'red')
$('#title').show()Vue (deklarativ):
// Du sagst dem Browser nur, „was" angezeigt werden soll
data() {
return {
title: "Neuer Titel",
color: "red",
visible: true
}
}👇 Probier es selbst aus: Vergleiche den imperativen und deklarativen Ansatz
// Manually operate the DOM
$('#count').text(val);
if (val > 5) $('#msg').show(); // Bind data only
{{ count }}
<div v-if="count > 5">...</div> 💡 Imperativ vs. Deklarativ
Es ist wie beim Malen eines Bildes:
- Imperativ: Du sagst dem Maler: „Nimm den Pinsel, tauche ihn in rote Farbe, male einen Kreis an Position (10,10)"
- Deklarativ: Du gibst dem Maler einfach ein Foto und sagst: „Mal es genau so"
Vue/React sind „deklarativ": Du beschreibst, „wie die Seite aussehen soll", das Framework kümmert sich darum, „wie sie gezeichnet wird".
4.3 Komponentisierung: Seiten bauen wie mit Lego
Die mächtigste Eigenschaft von Vue / React ist die Komponentisierung: Die Seite wird in unabhängige „Bausteine" zerlegt.
Stell dir vor, du baust mit Lego:
- Du musst nicht „jeden Stein von Grund auf neu schnitzen" (HTML/CSS von Grund auf schreiben)
- Du musst nur „die Steine nach Anleitung zusammenstecken" (Komponenten kombinieren)
- Jeder Stein ist unabhängig und kann in verschiedenen Sets wiederverwendet werden
Vorteile von Komponenten:
- Wiederverwendung: Eine „Produktkarten"-Komponente schreiben und 100-mal verwenden
- Kapselung: Der interne Zustand einer Komponente beeinflusst andere nicht
- Wartung: Eine Komponente ändern – alle Stellen, die sie verwenden, werden aktualisiert
💡 Erkennungstipps
<ComponentName />→ Das ist eine Komponenteimport xxx from './xxx.vue'→ Eine Komponente wird importiertprops: {...}→ Parameter, die die Komponente empfängtemit('xxx')→ Die Komponente sendet ein Ereignis an die Elternkomponente
4.4 SPA: Die Geburt der Single-Page Application
In der Vue / React-Ära gab es noch eine wichtige Veränderung: von MPA zu SPA.
MPA (Multi-Page Application):
- Ein Link klicken → Ganze Seite neu laden → Neue Seite anzeigen
- Wie ein Buch umblättern: Bei jedem Umblättern das alte Buch schließen, ein neues aus dem Regal holen
SPA (Single-Page Application):
- Ein Link klicken → Nur der Inhaltsbereich wird aktualisiert → Die Seite lädt nicht neu
- Wie ein Kapitelwechsel im selben Buch: Nur der alte Inhalt wird gelöscht, neuer Inhalt geschrieben
👇 Probier es selbst aus: Erlebe den Unterschied zwischen MPA und SPA
Vorteile von SPA:
- ✅ Flüssige UX: Schnelle Seitenwechsel
- ✅ Einfaches Zustandsmanagement: Eingaben und Scrollpositionen bleiben erhalten
- ❌ Erster Ladevorgang kann langsam sein: JavaScript muss zuerst heruntergeladen werden
- ❌ SEO erfordert zusätzliche Maßnahmen: Suchmaschinen können Inhalte möglicherweise nicht erfassen (SSR/SSG nötig)
5. Rendering-Strategien: Von CSR zu SSR/SSG
🤔 Kernfrage
Wird die Seite auf dem Server oder im Browser generiert? Verschiedene Rendering-Strategien haben unterschiedliche Vor- und Nachteile – die richtige Wahl ist entscheidend für Performance und SEO.
CSR (Client-Side Rendering):
- Browser lädt JavaScript herunter → Führt Code aus → Generiert die Seite
- Vorteile: Flüssige Interaktion, geringe Serverlast
- Nachteile: Langsamer erster Ladevorgang, schlecht für SEO
SSR (Server-Side Rendering):
- Server generiert HTML → Sendet es an den Browser → Browser zeigt es direkt an
- Vorteile: Schneller erster Ladevorgang, gut für SEO
- Nachteile: Hohe Serverlast, komplexe Implementierung
SSG (Static Site Generation):
- HTML aller Seiten wird beim Build generiert
- Vorteile: Extrem schnell, vollständig statisch, CDN-freundlich
- Nachteile: Nicht für dynamische Inhalte geeignet
👇 Probier es selbst aus: Vergleiche die Eigenschaften verschiedener Rendering-Strategien
💡 Wie wählt man aus?
- Content-Websites (Blogs, Dokumentation): SSG bevorzugen
- Dynamische Websites mit SEO-Bedarf (E-Commerce, Nachrichten): SSR verwenden
- Backend-Admin-Systeme: CSR verwenden
- Gemischte Anforderungen: Hybrides Rendering mit Nuxt/Next.js in Betracht ziehen
6. Phase 4: Engineering und Build-Tools (2015er–2020er)
🤔 Kernfrage
Warum braucht das Frontend „Engineering"? Was machen Build-Tools eigentlich? Nur wenn du Engineering verstehst, kannst du den Workflow moderner Frontend-Projekte nachvollziehen.
6.1 Warum brauchen wir „Engineering"?
Frontend-Projekte werden immer größer – „Skripte manuell einbinden" reicht nicht mehr aus.
Engineering bedeutet, mit Tools und Standards die Entwicklung effizienter, den Code zuverlässiger und die Zusammenarbeit reibungsloser zu machen.
💡 Engineering = Von der „Handwerkswerkstatt" zur „modernen Fabrik"
Stell dir vor, du kochst zu Hause vs. du betreibst ein Restaurant:
- Zu Hause kochen: Du kochst, worauf du Lust hast, völlig frei
- Restaurant betreiben: Standardisierte Rezepte, normierte Arbeitsabläufe, einheitlicher Einkauf
Genauso ist es in der Frontend-Entwicklung:
- Kleine Projekte: Du kannst schreiben, wie du willst
- Große Projekte: Einheitliche Code-Standards, automatisierte Tools, standardisierte Prozesse sind nötig
6.2 Build-Tools: Webpack → Vite
Webpack (traditionell):
- Arbeitsweise: Erst bündeln, dann bereitstellen
- Beim Start: Gesamten Code bündeln → Server starten
- Problem: Langsam. Je größer das Projekt, desto langsamer der Start (bis zu 30 Sekunden)
Vite (modern):
- Arbeitsweise: On-Demand-Kompilierung
- Beim Start: Kein Bündeln, Server startet direkt
- Der Browser fordert eine Datei an – sie wird in Echtzeit kompiliert
- Vorteil: Schnell. Startet normalerweise in unter 1 Sekunde
| Vergleich | Webpack | Vite | Verbesserung |
|---|---|---|---|
| Kaltstart | 30s+ | <1s | 30× schneller |
| Hot Reload | 3–5s | <100ms | 30× schneller |
| Konfigurationsdatei | Hunderte Zeilen | Dutzende Zeilen | Deutlich vereinfacht |
💡 Warum ist Vite so schnell?
Webpack ist wie ein Umzug mit komplettem Hausstand: Erst alles einpacken, dann losgehen.
Vite ist wie Reisen mit leichtem Gepäck: Nur das Nötigste mitnehmen, den Rest bei Bedarf kaufen.
In der Entwicklungsumgebung bearbeitest du meist nur wenige Dateien – Vite kompiliert nur diese wenigen Dateien, daher ist es natürlich schnell.
7. Vergleich der wichtigsten Frameworks
🤔 Kernfrage
Welche Besonderheiten haben Vue, React, Svelte und Angular? Wie wählt man das passende Framework aus? Nur wenn du ihre Designphilosophien und Anwendungsfälle kennst, kannst du eine kluge Wahl treffen.
7.1 Vergleich der vier großen Frameworks
| Eigenschaft | Vue | React | Svelte | Angular |
|---|---|---|---|---|
| Designphilosophie | Progressives Framework | UI-Bibliothek | Compile-Time-Framework | Vollständige Plattform |
| Lernkurve | ⭐⭐ Einfach | ⭐⭐⭐ Mittel | ⭐⭐ Einfach | ⭐⭐⭐⭐ Steil |
| Performance | Schnell | Schnell | Extrem schnell | Schnell |
| Ökosystem | Ausgereift | Am ausgereiftesten | Wachsend | Ausgereift |
| Paketgröße | Klein | Mittel | Am kleinsten | Groß |
| Geeignete Szenarien | Kleine bis mittlere Projekte | Große Projekte | Hohe Performance-Anforderungen | Enterprise-Anwendungen |
| Unterstützung | Evan You (unabhängig) | Meta | Community |
7.2 Vue: Progressives Framework
Kernphilosophie: Schrittweise Einführung – du kannst nur einen Teil nutzen oder das gesamte Ökosystem
<template>
<div>{{ message }}</div>
</template>
<script>
export default {
data() {
return {
message: 'Hello Vue'
}
}
}
</script>Vorteile:
- ✅ Flache Lernkurve, umfassende chinesische Dokumentation
- ✅ Intuitive Template-Syntax, leicht verständlich
- ✅ Klare Struktur durch Single-File Components (.vue)
- ✅ Geeignet für schnelle Entwicklung
Nachteile:
- ❌ Zustandsmanagement in großen Projekten erfordert zusätzliches Lernen von Vuex/Pinia
- ❌ Etwas weniger Flexibilität als React
Geeignete Szenarien:
- Kleine bis mittlere Webanwendungen
- Schnelles Prototyping
- Chinesische Teams (dokumentationsfreundlich)
7.3 React: UI-Bibliothek
Kernphilosophie: Nur für die View-Schicht zuständig, andere Probleme überlässt man der Community
function App() {
const [message, setMessage] = useState('Hello React')
return <div>{message}</div>
}Vorteile:
- ✅ Das ausgereifteste Ökosystem, reichhaltige Komponentenbibliotheken
- ✅ Flexible JSX-Syntax, hohe Ausdruckskraft
- ✅ Hervorragende Performance durch Virtual DOM
- ✅ Geeignet für große Projekte
Nachteile:
- ❌ Steilere Lernkurve, zusätzliche Konzepte müssen beherrscht werden
- ❌ Verschiedene Bibliotheken müssen selbst ausgewählt und kombiniert werden
- ❌ JSX muss kompiliert werden, läuft nicht direkt im Browser
Geeignete Szenarien:
- Große, komplexe Anwendungen
- Projekte, die ein reichhaltiges Ökosystem benötigen
- Plattformübergreifende Entwicklung (React Native)
7.4 Svelte: Compile-Time-Framework
Kernphilosophie: Kein Virtual DOM – Komponenten werden zur Build-Zeit in effizienten nativen Code umgewandelt
<script>
let message = 'Hello Svelte'
</script>
<div>{message}</div>Vorteile:
- ✅ Beste Performance (kein Virtual-DOM-Laufzeit-Overhead)
- ✅ Kleinste Paketgröße
- ✅ Einfache, intuitive Syntax
- ✅ Reaktivitätssystem nativ integriert
Nachteile:
- ❌ Relativ kleines Ökosystem
- ❌ Kleinere Community als Vue/React
- ❌ Weniger Drittanbieter-Bibliotheken
Geeignete Szenarien:
- Anwendungen mit extremen Performance-Anforderungen
- Projekte, bei denen die Paketgröße kritisch ist
- Teams, die bereit sind, neue Technologien auszuprobieren
7.5 Angular: Vollständige Plattform
Kernphilosophie: Eine komplette Lösung, sofort einsatzbereit
@Component({
selector: 'app-root',
template: '<div>{{ message }}</div>'
})
export class AppComponent {
message = 'Hello Angular'
}Vorteile:
- ✅ Vollständige Funktionalität – Routing, HTTP, Formulare, alles enthalten
- ✅ Native TypeScript-Unterstützung
- ✅ Geeignet für große Teams und Projekte
- ✅ Einheitliche Code-Standards
Nachteile:
- ❌ Steile Lernkurve
- ❌ Viele Konzepte, hohe Komplexität
- ❌ Große Paketgröße
- ❌ Nicht für kleine Projekte geeignet
Geeignete Szenarien:
- Große Enterprise-Anwendungen
- Teams, die strenge Standards benötigen
- Projekte mit bestehendem TypeScript-Stack
8. Zusammenfassung: Das Wesen der Evolution
Die Evolution der Frontend-Technologien löst im Kern zwei Probleme:
8.1 Effizienz: Von manuell zu automatisch
| Ära | Entwicklungsmethode | Effizienz |
|---|---|---|
| 2000er | HTML/CSS/JS von Hand schreiben | ⭐ |
| 2010er | jQuery + manuelle DOM-Operationen | ⭐⭐ |
| 2020er | Vue/React + datengetrieben | ⭐⭐⭐ |
| Heute | Komponentisierung + Engineering + Automatisierung | ⭐⭐⭐⭐⭐ |
8.2 Skalierung: Vom Einzelnen zum Team
| Ära | Projektgröße | Zusammenarbeit |
|---|---|---|
| 2000er | Ein paar Dateien | Eine Person kann es warten |
| 2010er | Dutzende Dateien | Kleines Team, häufige Konflikte |
| 2020er | Hunderte Dateien | Mittleres Team, Standards nötig |
| Heute | Tausende Dateien | Großes Team, vollständiges Engineering-System nötig |
9. Lern-Roadmap
9.1 Wenn du bei Null anfängst
Schritt 1: HTML/CSS/JavaScript-Grundlagen
- Die drei Grundpfeiler des Webs verstehen
- Einfache statische Seiten erstellen können
Schritt 2: Ein Framework lernen (Vue empfohlen)
- Das „datengetriebene" Denken verstehen
- Komponentenbasierte Entwicklung beherrschen
Schritt 3: Praxisprojekt
- Eine vollständige Single-Page Application bauen
- Routing, Zustandsmanagement und API-Aufrufe beherrschen
9.2 Wenn du Vorkenntnisse hast
Fortgeschrittene Richtungen:
- Engineering: Vite/Webpack lernen, den Build-Prozess verstehen
- Performance-Optimierung: Lazy Loading, Code Splitting, Caching-Strategien lernen
- TypeScript: Typen zum Code hinzufügen, Zuverlässigkeit erhöhen
- Server-Side Rendering: Nuxt/Next.js lernen, SEO- und First-Load-Probleme lösen
10. Was du jetzt erkennen können solltest
Nach dem Lesen dieses Kapitels solltest du in der Lage sein:
- ✅ Den roten Faden und die Gründe der Frontend-Evolution zu verstehen
- ✅ Die Besonderheiten von Vue, React, Svelte und Angular zu unterscheiden
- ✅ Den Unterschied zwischen „imperativ" und „deklarativ" zu verstehen
- ✅ Das Kernkonzept „datengetrieben" zu beherrschen
- ✅ Den Wert der komponentenbasierten Entwicklung zu kennen
- ✅ Die Anwendungsfälle von CSR, SSR und SSG zu kennen
- ✅ Die Rolle von Build-Tools (Webpack, Vite) zu verstehen
- ✅ Das passende Framework und den Tech-Stack für ein Projekt auswählen zu können
💡 Praktische Anwendung
Wenn du mit KI ein Projekt machst, kannst du ihr so Bescheid geben:
- „Das ist eine Blog-Website, die SEO braucht – verwende Nuxt (Vues SSR-Framework)"
- „Das ist ein Admin-Backend – verwende Vue + Element Plus, kein SSR nötig"
- „Das ist eine Webanwendung mit hohen Performance-Anforderungen – ziehe Svelte in Betracht"
- „Das Projekt verwendet bereits React – bleib bei den Bibliotheken aus dem React-Ökosystem"
Glossar
| Begriff | Englisch | Einfach erklärt |
|---|---|---|
| DOM | Document Object Model | Dokumentobjektmodell. Stellt die Seite als Objektbaum dar, der von JS gelesen und geschrieben werden kann. |
| jQuery | - | Früher weit verbreitete JS-Bibliothek, die DOM-Operationen vereinfachte. |
| Vue/React | - | Moderne Frontend-Frameworks mit datengetriebenem und komponentenbasiertem Ansatz. |
| Komponente | Component | Wiederverwendbare UI-Einheit, z. B. Button, Karte, Navigationsleiste. |
| MPA | Multi-Page Application | Mehrseitenanwendung. Bei jedem Seitenwechsel wird die gesamte Seite neu geladen. |
| SPA | Single-Page Application | Einzelseitenanwendung. Wird nur einmal geladen, weitere Wechsel laden die Seite nicht neu. |
| Routing | Routing | Verwaltet die Regeln und den Ablauf des Wechsels zwischen Seiten. |
| SSR | Server-Side Rendering | Serverseitiges Rendering. Der Server generiert HTML und sendet es an den Browser. |
| SSG | Static Site Generation | Statische Seitengenerierung. Seiten werden beim Build als statisches HTML vorgerendert. |
| CSR | Client-Side Rendering | Clientseitiges Rendering. Der Browser generiert die Seite per JavaScript. |
| Webpack | - | Traditionelles Build-Tool, erst bündeln, dann bereitstellen. |
| Vite | - | Modernes Build-Tool, On-Demand-Kompilierung, extrem schnell. |
| Responsive | Responsive Design | Design, das sich automatisch an verschiedene Bildschirmgrößen anpasst. |
| Media Query | Media Query | CSS-Bedingungsprüfung, wendet je nach Bildschirmbreite unterschiedliche Styles an. |
| Imperativ | Imperative | Dem Programm sagen, „wie" es etwas tun soll. |
| Deklarativ | Declarative | Dem Programm sagen, „was" es erreichen soll. |
| Datengetrieben | Data-Driven | Nur die Daten ändern, die Benutzeroberfläche aktualisiert sich automatisch. |
| Tree Shaking | - | Baum-Schüttel-Optimierung. Entfernt automatisch ungenutzten Code, reduziert die Paketgröße. |
| Code Splitting | Code Splitting | Code in mehrere kleine Teile aufteilen und bei Bedarf laden. |