Frontend

Die Heilige Dreifaltigkeit:

1. HTML: Die Struktur (Skelett). <h1>Überschrift</h1>.
2. CSS: Das Aussehen (Haut/Kleidung). h1 { color: red; }.
3. JavaScript: Das Verhalten (Muskeln). button.onclick = () => alert("Hallo!").

Frameworks: Heute baut kaum jemand "rohes" JS. Man nutzt React, Vue oder Angular. Warum? Weil es schwer ist, den Zustand ("Warenkorb hat 3 Items") manuell mit dem DOM ("Zeige Zahl 3") synchron zu halten. React macht das automatisch.

1. SPA vs. MPA

• MPA (Multi Page Application): Alter Stil (PHP/WordPress). Klick auf Link -> Seite lädt komplett neu (weißer Blitz).
• SPA (Single Page Application): Neuer Stil (Gmail/Trello). Klick auf Link -> JS lädt nur die neuen Daten (JSON) und tauscht den Inhalt aus. Kein Neuladen. Fühlt sich an wie eine App.
• Nachteil SPA: Schlechtes SEO (Google sieht leere Seite), langsamer erster Start (User lädt 5MB JS).
• Lösung: SSR (Server Side Rendering) mit Next.js. Erster Aufruf ist HTML (schnell), danach SPA.

2. The Build Step (Bundling)

Browser verstehen kein TypeScript, kein SASS und kein React JSX. Ein Bundler (Vite, Webpack) muss den Code übersetzen (Transpiling). Er macht auch "Tree Shaking": Löscht Code, der nie benutzt wird, damit die Datei klein bleibt.

3. Hydration

Bei SSR schickt der Server HTML. Der User sieht die Seite sofort. Aber der Button klickt noch nicht (weil JS noch lädt). Sobald JS da ist, "kapert" React das vorhandene HTML und macht es interaktiv. Das nennt man Hydration. "Uncanny Valley": Die Millisekunden, wo die Seite fertig aussieht, aber tot ist.

1. State Management Pattern (Flux/Redux)

In großen SPAs zerreißt es Anfänger beim Zustand (State). User ändert seinen Avatar in /profile. Die kleine Header-Bar oben rechts muss aber auch sofort das neue Bild zeigen. Wenn /profile den Header nicht kennt (Props Drilling ist zu tief), baut man das Flux-Pattern. Es gibt einen zentralen, unveränderbaren "Globus" an Daten (den Store). Kein Component darf die Daten anfassen. Um etwas zu ändern, feuert das Component eine asynchrone Action ab (type: UPDATE_IMAGE). Ein strenger Reducer (eine reine Funktion) berechnet aus Store + Action einen 100% frischen neuen State. Sobald der Store erneuert ist, reagieren alle View-Komponenten weltweit automatisch auf das Subskriptions-Event und rendern neu (Unidirectional Data Flow).

2. Browser Rendering Engine Constraints

Front-End Entwickler kämpfen hart mit der Pixel-Maschine. CSS ist nicht isoliert. Wenn du JavaScript ein komplexes div.getBoundingClientRect() fragst, muss die Engine sofort den laufenden DOM-Prozess pausieren, Layout und Reflow durchführen (Forced Synchronous Layout) und das System freezen, um die exakten Pixel-Maße zu berechnen (Layout Thrashing). Das killt flüssige 60 Frames-Per-Second (FPS) C-Scroll-Animationen. Echte Front-End Experten nutzen requestAnimationFrame(), um DOM-Lese/Schreib-Befehle genau synchron an den vertikalen Bildschirmaufbau (Refresh-Rate) des Monitors des Nutzers zu nageln.

3. Cross-Origin Resource Sharing (CORS) am Client

Der fieseste Error im Browser-DevTool. Dein Frontend läuft auf localhost:3000. Es schickt API-Zugriffe an api.firma.de. Der Browser hat einen Polizei-Mechanismus (SOP - Same Origin Policy) fest im C++ Kernel verbaut. Er sagt: "Halt! Frontend und Backend sind feindliche Domains." Der Browser schickt dann heimlich eine Preflight-Anfrage (OPTIONS Method) ans Backend: "Sag mal, Backend, erlaubst du, dass localhost dir Daten sendet?". Ist der Server falsch konfiguriert (fehlen die Headers Access-Control-Allow-Origin: *), bricht der Browser eiskalt den Payload des Calls als Sicherheitsrisiko blockierend ab. Das JavaScript stürzt ab mit einer roten CORS Policy Veto Error Exception, ohne dass je ein Byte angekommen ist.