Begriff
SPA (Single Page Application)
Warum wichtig?
Dieser Begriff ist ein Knoten im SengakujiWorks-Wissensnetz. Nutze Level 0 für die erste Einordnung, Level 1 für Praxis, Level 2 für technische Struktur und Level 3 für Grenzen, Fallstricke und Expertenkontext.
Früher (MPA): Klick auf "Über uns" -> Browser wird weiß -> Server schickt neue HTML-Datei -> Browser baut alles neu auf. Heute (SPA): Klick auf "Über uns" -> Browser bleibt ruhig. JavaScript holt nur den Text "Über uns" vom Server (als JSON). Javascript tauscht den Text in der Mitte der Seite aus. Das Menü und der Footer bleiben stehen. Es fühlt sich an wie eine installierte App (flüssig, keine Ladezeiten). Beispiele: Gmail, Facebook, Trello.
Merksatz: Eine Webanwendung, die nur eine einzige HTML-Datei lädt und alle weiteren Inhalte dynamisch per JavaScript nachlädt, ohne die Seite neu zu laden.
Frameworks: React, Vue, Angular, Svelte. Ohne Framework ist eine SPA schwer zu bauen (History-Management, State-Sync).
Client-Side Routing:
Die URL ändert sich trotzdem (myapp.com/about).
Aber der Browser lädt nicht neu.
Das macht der Router (z. B. React Router). Er fängt den Klick ab, ändert die URL in der Leiste (via history.pushState) und sagt der App: "Zeig jetzt Komponente X".
1. Das SEO-Problem
Google Bot kommt auf die Seite.
Er sieht: <div id="root"></div> und <script src="app.js">.
Wenn der Bot kein JS ausführt (tat er früher nicht), sieht er eine weiße Seite.
Lösung: Server Side Rendering (SSR) (Next.js). Der Server führt das React-Render einmal aus und schickt fertiges HTML an den Bot.
2. State Management (Redux/Zustand)
In einer SPA lebst du lange auf einer Seite. User klickt "Warenkorb". User geht zurück zur "Liste". User geht wieder zum "Warenkorb". Soll der Warenkorb neu geladen werden? Oder haben wir die Daten noch im RAM? State-Management-Libraries speichern Daten global im Speicher, damit man nicht unnötig oft die API fragt.
3. Memory Leaks
Bei MPA: Nach jedem Klick (Reload) wird der RAM gelöscht (frischer Start). Bei SPA: Der User ist 4 Stunden lang auf der Seite. Wenn dein JS Müll produziert (Event Listener nicht entfernt, Arrays werden immer größer), stürzt der Tab irgendwann ab ("Out of Memory"). Ein SPA-Entwickler muss sehr sauber programmieren (Cleanup Functions).
Das Hydration Problem & SSR
Wenn Server Side Rendering (SSR, z. B. in Next.js) das fertige <html> an den Browser schickt, ist das SEO-Problem gelöst. Der User sieht die Seite sofort voll aufgebaut (Top First Paint).
Doch das DOM ist in diesem Moment "tot" (keine Event-Listener auf den Buttons).
React muss nun im Hintergrund reagieren: Es lädt die dicken JS-Bundles herunter, baut den Virtual DOM virtuell exakt so auf, wie das HTML aussieht, und "klebt" dann die interaktiven Funktionen (OnClick) über die statischen HTML-Knoten. Dieser Prozess heißt Hydration.
Gotcha: Wenn der Server das <div id="clock">12:00</div> rendert, der User aber erst um 12:01 auf der Seite ankommt und React dort hydriert, schreit React wegen eines Mismatch-Errors! Das Server-HTML unterscheidet sich vom Client-Render. Hydration bricht dann ab oder rendert die App extrem asynchron und teuer im Client neu.
Code Chunking und Lazy Loading
Das größte SPA-Gift ist die Initial Payload Size.
Wenn die App (inkl. Dashboard, Settings, Data-Tables) in eine monströse app-48f9z.js Datei (3 Megabyte) gepackt wird, starrt ein Smartphone-User im 3G-Netz sekundenlang auf einen weißen Screen.
Profis nutzen Webpack/Vite für Route-based Code Splitting (Lazy Loading).
Der Bundler zerschneidet die App. Besucht der User das Login, lädt der Browser nur die login.js (50 KB) plus react.js. Erst wenn der User auf "Admin Area" navigiert, fetched der SPA-Router on-the-fly (import('./admin.tsx')) asynchron das admin.chunk.js File. Die gefühlte Ladezeit implodiert.
Das BFF Pattern (Backend for Frontend)
SPAs rufen APIs direkt auf. Liegen die Rohdaten auf 5 Microservices (Auth, Catalog, Cart), müsste der Browser vom Smartphone aus 5 teure HTTP/SSL-Roundtrips übers Netz feuern ("N+1 Query Problem im Frontend").
Die Architektur-Lösung ist das BFF Pattern (Backend for Frontend).
Man baut z. B. einen winzigen Node/GraphQL Server, der rein als Gateway für die React-SPA dient. Die SPA schießt exakt einen HTTP-Request (GET /dashboard-ui-data) an das BFF. Das BFF (welches mit Glasfaser im Backend-RZ steht) sammelt die Daten aller Microservices mit 1 Millisekunde Latenz ein, schrumpft sie auf das Wesentliche, und flippt das perfekte JSON-Paket zurück ans Smartphone.
Quick-Check
PWA (Progressive Web App)?
Eine SPA, die man "installieren" kann (auf den Homescreen). Sie funktioniert auch offline (Service Worker).Initial Load Time?
Nachteil von SPAs. Du musst erst 2MB JavaScript laden, bevor irgendwas passiert. Lösung: Code Splitting (Lade "Admin-Bereich" erst, wenn User draufklickt).Hash Router?
myapp.com/#/about. Alter Trick. Alles nach#wird nicht an den Server gesendet. Browser springt nur intern. Heute nutzt man den "Browser Router" (HTML5 History API) für "echte" URLs.