Jede JavaScript Animation Library, die du mit 3 Zeilen CSS ersetzen kannst

Ich bin ehrlich. Letzten Monat habe ich mich dabei erwischt, wie ich GSAP in ein Kundenprojekt installiert habe, nur um ein paar Karten beim Scrollen einzublenden. Dreissig Kilobyte JavaScript. Damit ein Div von unsichtbar zu sichtbar wird.

Da habe ich gestoppt und mich gefragt: Brauche ich das wirklich, oder mache ich einfach das, was ich schon immer gemacht habe?

Es stellt sich heraus, dass die meisten Animationen, fuer die ich JavaScript Libraries gebraucht habe, jetzt natives CSS sind. Nicht "kommt bald." Nicht "hinter einem Flag." Jetzt in Browsern verfuegbar. Und der Performance-Unterschied ist nicht subtil.

Du lieferst 30KB JavaScript aus, um ein Div einzublenden

Animation Libraries sind die Kramschublade der Webentwicklung. Du ziehst eine fuer einen einzigen Fade-In-Effekt rein, und ploetzlich laedt jede Seite deiner Website 30 bis 60 Kilobyte JavaScript, die der Browser herunterladen, parsen, kompilieren und ausfuehren muss, bevor sich irgendetwas bewegt.

Ich habe das oefter gemacht, als mir lieb ist. Ein Kunde will Scroll-Animationen, ich greife zu AOS, weil ich es kenne. Ein anderer Kunde will Page Transitions, ich installiere Framer Motion, weil die Docs gut sind. Kein einziges Mal habe ich geprueft, ob der Browser das einfach selbst kann.

Diese Gewohnheit hat meine Kunden echte Performance gekostet. Jedes Byte JavaScript kostet mehr als ein Byte CSS, weil JS auf dem Main Thread geparst und ausgefuehrt werden muss. CSS-Animationen laufen auf dem Compositor Thread und bekommen GPU-Beschleunigung gratis.

Die Library-Steuer, ueber die niemand spricht

Lass mich das in Zahlen fassen. Das ist, was du tatsaechlich auslieferst, wenn du diese Libraries installierst:

GSAP core kommt auf ungefaehr 23KB gzipped. Mit ScrollTrigger bist du bei 41KB. Framer Motion (jetzt Motion) ist etwa 32KB gzipped. AOS ist 14KB. Animate.css ist 18KB. Und wenn du Lottie-web benutzt, schaust du auf 80KB oder mehr.

Das sind keine kleinen Zahlen. Motion allein bekommt 3,6 Millionen woechentliche Downloads. GSAP bekommt 1,47 Millionen. Das sind viele Projekte, die viel JavaScript ausliefern fuer Animationen, die CSS nativ kann.

Die Auswirkung auf Core Web Vitals ist real. JavaScript-Animationen blockieren den Main Thread, was direkt deine Interaction to Next Paint (INP) und Largest Contentful Paint (LCP) Werte verschlechtert. CSS-Animationen haben dieses Problem nicht, weil sie den Main Thread komplett umgehen.

Fade In beim Scrollen? Das sind jetzt 3 Zeilen CSS

Das ist der grosse Punkt. Der Grund, warum die meisten Leute AOS oder GSAP ScrollTrigger installieren, sind scroll-getriggerte Animationen. Elemente, die einblenden, hochsliden oder skalieren, wenn sie im Viewport erscheinen.

Der alte Weg mit AOS: Du importierst die Library, fuegst data-aos="fade-up" Attribute in dein HTML ein, rufst AOS.init() in deinem JavaScript auf und verlinkst das AOS Stylesheet. Vier Schritte, zwei Dateien, eine Dependency.

Der neue Weg:

@keyframes fade-in {
  from { opacity: 0; translate: 0 20px; }
  to { opacity: 1; translate: 0; }
}

.animate-on-scroll {
  animation: fade-in linear both;
  animation-timeline: view();
  animation-range: entry 0% entry 100%;
}

Drei Properties. Kein JavaScript. Keine Dependencies. Keine Event Listener. Der Browser uebernimmt alles, und es laeuft auf dem Compositor Thread, also butterweiches Scrollen auch auf langsameren Geraeten.

Ich habe ueber eine aehnliche Philosophie in meinem Post ueber das Ersetzen von WordPress Plugins durch nativen Code geschrieben. Gleiches Prinzip: Kenne deine Plattform, und du brauchst weniger Abstraktionen.

Browser-Support: Chrome 115+, Safari 18+. Firefox ist noch hinter einem Flag, aber du kannst @supports (animation-timeline: view()) fuer Progressive Enhancement nutzen. Die Animation spielt einfach nicht in nicht unterstuetzten Browsern, was ein voellig akzeptabler Fallback ist.

Scroll-verknuepfte Fortschrittsbalken ohne einen einzigen Event Listener

Lese-Fortschrittsbalken brauchten frueher Scroll Event Listener, requestAnimationFrame Loops und sorgfaeltiges Throttling, um Jank zu vermeiden. Mit GSAP ScrollTrigger war es sauberer, aber immer noch JavaScript.

Jetzt ist es das:

.progress-bar {
  position: fixed;
  top: 0;
  left: 0;
  width: 100%;
  height: 3px;
  background: var(--accent);
  transform-origin: left;
  animation: grow-bar linear;
  animation-timeline: scroll();
}

@keyframes grow-bar {
  from { transform: scaleX(0); }
  to { transform: scaleX(1); }
}

Kein JavaScript. animation-timeline: scroll() bindet die Animation direkt an die Scroll-Position der Seite. Wenn der User scrollt, waechst der Balken. Der Browser macht die ganze Berechnung.

Elemente von display:none animieren

Das ist ein echter Game Changer. Wenn du jemals React Transition Group oder Framer Motions AnimatePresence benutzt hast, kennst du den Schmerz, Elemente von display: none zu display: block zu animieren. CSS konnte das nicht. Deshalb gab es Animation Libraries im React-Oekosystem.

@starting-style loest das. Es laesst dich den "Vorher"-Zustand fuer das erste Erscheinen eines Elements definieren:

dialog[open] {
  opacity: 1;
  scale: 1;
  transition: opacity 0.3s, scale 0.3s, display 0.3s allow-discrete;
}

@starting-style {
  dialog[open] {
    opacity: 0;
    scale: 0.95;
  }
}

Das funktioniert fuer Dialoge, Popovers, jedes Element, das display toggled. Chrome 117+, Safari 17.5+, Firefox 129+. Das ist Cross-Browser Baseline in 2026.

Das war der Grund, warum Leute in React zu Animation Libraries gegriffen haben. Nicht mehr.

Page Transitions ohne React Router + Framer Motion

Die View Transitions API ist wahrscheinlich das beeindruckendste CSS-Feature, das ich seit Jahren gesehen habe. Same-Document Transitions funktionieren in Chrome 111+, Safari 18+ und Firefox 133+. Cross-Document Transitions fuer Multi-Page Apps sind seit Chrome 126+ verfuegbar.

Der alte Ansatz: FLIP-Berechnungen, Position Tracking, React State Management, hunderte Zeilen Code. Der neue Ansatz:

::view-transition-old(root) {
  animation: fade-out 0.2s ease;
}

::view-transition-new(root) {
  animation: fade-in 0.2s ease;
}

Fuer Multi-Page Apps fuegst du buchstaeblich nur eine CSS-Regel hinzu und der Browser uebernimmt das Cross-Page Morphing. Kein JavaScript Framework noetig. Das traegt direkt zu dem professionellen Webdesign-Gefuehl bei, das Kunden bemerken, aber nicht artikulieren koennen.

Height von 0 auf Auto animieren (Ja, endlich)

Jeder Webentwickler hat irgendwann versucht, height: auto zu animieren. Jeder Webentwickler ist gescheitert. Das war ein unloesbar scheinendes CSS-Problem seit ueber einem Jahrzehnt.

interpolate-size: allow-keywords loest es:

:root {
  interpolate-size: allow-keywords;
}

details[open] > .content {
  height: auto;
  transition: height 0.3s ease;
}

Sanfte Accordion-Animationen, <details> Elemente, die elegant oeffnen, zusammenklappbare Panels ohne Spruenge. Eine Zeile in deinem CSS Reset und es funktioniert einfach.

Vorbehalt: Das ist momentan nur Chromium (Chrome 129+, Edge 129+). Firefox und Safari unterstuetzen es noch nicht. Aber du kannst es als Progressive Enhancement hinzufuegen. In nicht unterstuetzten Browsern ist die Hoehenaenderung sofort, was das gleiche Verhalten ist, das jetzt schon alle haben.

Wann du weiterhin eine Library nutzen solltest

Ich werde nicht so tun, als wuerde CSS alles ersetzen. Tut es nicht. Hier solltest du deine JavaScript Animation Library behalten:

Komplexe sequenzierte Timelines. Wenn du 15 Elemente in einer bestimmten choreografierten Reihenfolge mit praezisem Timing animieren musst, ist GSAPs Timeline API immer noch unuebertroffen. CSS kann Animationen verketten, aber es wird schnell unuebersichtlich.

Physik-basierte Spring-Animationen. Framer Motions Spring Physics erzeugen ein Gefuehl, das CSS Easing Curves nicht replizieren koennen. Wenn dein Design von dieser federnden, natuerlichen Bewegung abhaengt, behalte die Library.

SVG Path Morphing. Lottie und GSAPs MorphSVG Plugin handlen komplexe Vektoranimationen, die CSS schlicht nicht kann.

Canvas und WebGL. Wenn du irgendetwas mit <canvas> machst, bist du sowieso in JavaScript-Territorium.

Meine Faustregel: Wenn du die Animation in einem Satz beschreiben kannst ("Fade In beim Scrollen," "Slide Up wenn sichtbar," "Fortschrittsbalken beim Scrollen"), kann CSS es. Wenn du einen Absatz brauchst, behalte die Library.

Gutes User Experience Design bedeutet, das richtige Tool fuer den Job zu nutzen, nicht das maechtigste Tool fuer jeden Job.

Die Migrations-Checkliste

Wenn du anfangen willst, JavaScript Animation Libraries durch CSS zu ersetzen, wuerde ich Folgendes tun:

1. Durchsuche deine Codebase. Suche nach gsap.to, gsap.from, data-aos, motion.div, animate__. Liste jede Animation auf, die du benutzt.

2. Kategorisiere jede einzelne. Kannst du sie in einem Satz beschreiben? Wenn ja, ist sie ein CSS-Kandidat. Wenn nein, markiere sie als "behalten."

3. Ersetze in der Reihenfolge des Impacts. Beginne mit scroll-getriggerten Animationen (groesste Bundle-Einsparung), dann Entry-Animationen (@starting-style), dann Page Transitions.

4. Nutze @supports fuer Progressive Enhancement. Wrappe CSS-Only Animationen in @supports Bloecke, damit nicht unterstuetzte Browser einfach nicht animieren statt zu brechen.

5. Teste in Safari und Firefox, nicht nur Chrome. Chrome ist bei einigen dieser Features voraus. Liefere nichts aus, das nur in Chromium funktioniert.

6. Miss vorher und nachher. Fuehre Lighthouse vorher und nachher aus. Die Bundle-Size-Reduktion allein sollte offensichtlich sein, aber die INP-Verbesserung ist das, was wirklich zaehlt.

Und waehrend du Dependencies aufraeumst, denk daran, dass weniger npm Packages auch eine kleinere Angriffsflaeche bedeuten. Jede Library, die du entfernst, ist ein Supply-Chain-Risiko weniger.

Die Web-Plattform hat aufgeholt, was Animation Libraries vor fuenf Jahren gemacht haben. Einiges davon ist leise passiert, einiges landet noch, aber genug davon ist heute produktionsreif, dass du zumindest jedes npm install hinterfragen solltest, das einem Div Bewegung hinzufuegt.

Ich sage nicht, wirf GSAP weg. Ich sage, hoer auf, es standardmaessig zu nutzen. Pruefe zuerst, was CSS kann. Du koenntest ueberrascht sein, wie oft die Antwort "alles, was du brauchst" lautet.

Wenn sich deine Website traege anfuehlt und du nicht weisst, wo du mit der Optimierung anfangen sollst, lass uns reden. Manchmal ist der groesste Performance-Gewinn, Code zu entfernen, nicht hinzuzufuegen.