Pourquoi supprimer JS des animations ?
JavaScript gère les animations sur le thread principal — le même thread qui gère les interactions utilisateur, le rendu DOM, et la logique applicative. Une animation JS qui tourne en même temps qu'un scroll peut provoquer des drops de framerate perceptibles. CSS, lui, peut déléguer certaines animations au GPU via des propriétés composées (transform, opacity).
Le résultat est mesurable : les animations CSS sont systématiquement plus fluides que leurs équivalents JS sur des appareils à performances modestes.
↑ Démo : wipe-reveal 100% CSS, aucun JS
Les 4 nouvelles armes de CSS Motion
Scroll-driven animations (lier une animation au scroll), View Transitions (transitions entre états DOM ou pages), @starting-style (animer l'apparition d'un élément depuis display:none), et l'interpolation de font-variation-settings constituent le quatuor qui rend JS largement superflu pour les interactions courantes.
.menu {
transition: opacity 0.3s, transform 0.3s;
opacity: 1;
transform: translateY(0);
}
@starting-style {
.menu {
opacity: 0;
transform: translateY(-8px);
}
}
« @starting-style est peut-être la fonctionnalité CSS la plus sous-estimée de 2024. Elle résout un problème que les développeurs contournaient avec JS depuis vingt ans. »
Ce que JS garde encore
Soyons honnêtes : JS reste nécessaire pour les animations pilotées par des données (graphiques temps réel, physics-based animations complexes), les gestes tactiles avancés (pinch-to-zoom, swipe avec momentum), et la synchronisation d'animations avec des événements métier.
Mais pour les transitions d'interface, les micro-interactions, les révélations au scroll et les transitions de navigation — CSS 2025 suffit largement. Et c'est un choix de professionnel que de l'utiliser.