Von VONA
Vanilla JS vs. Frameworks: Die ehrliche Abwägung
React, Vue, Svelte — großartige Tools. Aber nicht immer das richtige Werkzeug. Wann wir uns bewusst dagegen entscheiden und warum.
In der Webentwicklung gibt es kaum eine Frage, die so regelmäßig und so leidenschaftlich diskutiert wird wie die Wahl des JavaScript-Frameworks. React-Evangelisten, Vue-Enthusiasten, Svelte-Fans — alle haben ihre Argumente, und viele davon sind berechtigt. Was selten passiert: eine nüchterne Abwägung, die die Aufgabe selbst zum Ausgangspunkt macht, nicht die persönliche Präferenz oder den Trend auf Twitter.
Unsere Haltung ist pragmatisch: Wir setzen Frameworks dann ein, wenn sie die Arbeit einfacher machen — und verzichten darauf, wenn sie es nicht tun. Das klingt selbstverständlich, ist es in der Praxis aber nicht. Der Reflex, ein neues Projekt automatisch mit dem vertrauten Framework-Stack zu starten, ist stark. Er führt aber dazu, dass eine einfache Landingpage mit demselben Aufwand aufgebaut wird wie eine komplexe Webanwendung — und am Ende schlechter performt, weil sie einen hundert Kilobyte schweren JavaScript-Bundle lädt, den sie schlicht nicht braucht.
Wann Frameworks ihren Preis wert sind
Komplexe, interaktive Webanwendungen mit geteiltem State über viele Komponenten hinweg, dynamische Daten, die in Echtzeit aktualisiert werden, oder Teams, die auf einem gemeinsamen Framework-Standard aufbauen möchten — das sind legitime Gründe für den Einsatz von React, Vue oder ähnlichen Werkzeugen. Die Abstraktionen, die diese Frameworks bieten, machen in diesen Kontexten die Entwicklung schneller, den Code strukturierter und die Zusammenarbeit im Team einfacher.
Für Content-fokussierte Websites, Marketing-Seiten, Blogs oder Portale mit hauptsächlich statischen Inhalten hingegen ist der Overhead oft nicht gerechtfertigt. Hier leistet serverseitiges Rendering mit einem Static Site Generator — oder schlicht plain HTML — mehr: schnellere Ladezeiten, bessere Suchmaschinenindizierung, einfachere Caching-Strategien und deutlich weniger Abhängigkeiten, die gepflegt werden müssen.
Was Vanilla JS heute kann
Wer seit Jahren nicht mehr in nativem JavaScript geschrieben hat, unterschätzt, was die Plattform mittlerweile bietet. ES6+ mit Modules, Destructuring, async/await, Fetch API, IntersectionObserver, Custom Elements — vieles, wofür man vor fünf Jahren noch Libraries brauchte, ist heute nativ verfügbar. Die Browser-Unterstützung ist so gut wie nie. Wer diese Werkzeuge kennt, kann erstaunlich viel ohne externen Code erreichen.
- Native ES Modules für saubere Code-Organisation ohne Build-Step
- IntersectionObserver für Scroll-Animationen ohne Library
- Fetch API für HTTP-Anfragen ohne Axios oder ähnliches
- Custom Elements für wiederverwendbare Komponenten ohne Framework
Das Fazit ist einfach: Die Wahl zwischen Vanilla JS und einem Framework sollte von der Aufgabe abhängen, nicht vom Gewohnheitsreflex. Wer beide Optionen wirklich beherrscht, trifft diese Entscheidung besser — und liefert am Ende Produkte, die zum Problem passen, nicht zur favorisierten Technologie.