Chapitre 63 : Arbitrage : CSS natif vs JavaScript pour la gestion d'état

Comparaison des performances, analyse des limites de l'interactivité purement CSS et stratégies d'arbitrage architectural.

En tant qu'ingénieur front-end senior, l'une des décisions les plus critiques lors de la conception d'une interface n'est pas "comment" implémenter une fonctionnalité, mais "où" doit résider l'état de cette fonctionnalité. Pendant des années, le réflexe a été de déléguer toute logique d'état à JavaScript (JS). Cependant, avec l'évolution des spécifications CSS (notamment l'arrivée de :has()), la frontière s'est déplacée.

L'arbitrage entre CSS natif et JavaScript ne repose pas seulement sur la facilité d'écriture, mais sur trois piliers : la performance du rendu, l'accessibilité (A11y) et la maintenabilité.

L'État en CSS : Le moteur déclaratif

1. Quoi

La gestion d'état en CSS consiste à utiliser des pseudo-classes, des pseudo-éléments et des sélecteurs de relation pour modifier l'apparence d'un élément en fonction de son état interne ou de l'état de ses parents/enfants.

L'état CSS est intrinsèquement déclaratif : on ne dit pas au navigateur "quand l'utilisateur clique, change la couleur", on lui dit "si cet élément est dans l'état :checked, alors son voisin doit être rouge".

2. Pourquoi

L'utilisation du CSS pour l'état offre des avantages massifs en termes de performance. Le moteur de rendu du navigateur peut optimiser les transitions et les animations CSS sur le Composite Thread (fil de composition), évitant ainsi de solliciter le Main Thread (fil principal) où s'exécute le JavaScript. Cela garantit une fluidité à 60fps (ou plus), même si le fil principal est saturé par des calculs lourds.

3. Comment

A. Syntaxe de base (L'état simple)

L'état le plus basique repose sur les pseudo-classes d'interaction.

.button {
  background-color: blue;
  transition: background-color 0.3s ease;
}

/* État : Survol */
.button:hover {
  background-color: darkblue;
}

/* État : Focus (Accessibilité clavier) */
.button:focus-visible {
  outline: 3px solid orange;
}

B. Cas concret : Le pattern de gestion d'état complexe avec :has()

Le sélecteur :has() est le "sélecteur parent" tant attendu. Il permet de gérer des états complexes sans une seule ligne de JS.

/* 
  Objectif : Modifier le style d'une carte 
  SI un input à l'intérieur est coché.
*/

.card {
  border: 2px solid gray;
  padding: 1rem;
  transition: border-color 0.3s;
}

/* 
  L'état est porté par l'input, mais le style 
  est appliqué au parent .card 
*/
.card:has(input[type="checkbox"]:checked) {
  border-color: green;
  background-color: #f0fff0;
}

.card-title {
  color: black;
}

/* On peut même cibler d'autres enfants en fonction de l'état d'un frère */
.card:has(input:checked) .card-title {
  color: green;
  font-weight: bold;
}

C. Limitations

Le CSS pur a des limites structurelles :

1. Absence de mémoire persistante : Le CSS ne peut pas "se souvenir" d'un état après un rafraîchissement de page ou naviguer entre des pages.
2. Logique booléenne limitée : Bien que :not() et :has() permettent des combinaisons, on ne peut pas implémenter de logique conditionnelle complexe (ex: "si A et B sont vrais, mais pas C").
3. Sémantique et A11y : Le "Checkbox Hack" (utiliser un input caché pour gérer un menu) est souvent mal perçu par les lecteurs d'écran s'il n'est pas parfaitement implémenté.

4. Zone de Danger

❌ Erreur commune : Utiliser JavaScript pour ajouter/supprimer des classes CSS lors d'un survol (onMouseEnter → element.classList.add('active')). Cela provoque un "round-trip" inutile vers le Main Thread et peut créer un léger décalage visuel (jank).

✅ Bonne pratique : Utiliser :hover ou :focus-within pour tout ce qui est purement visuel. Réserver JS pour les changements d'état qui impactent les données ou la structure du DOM.

Arbre de décision : CSS vs JS pour l'état

L'État en JavaScript : Le moteur impératif

1. Quoi

La gestion d'état en JS consiste à stocker une valeur dans la mémoire (variable, store, state de composant) et à synchroniser cette valeur avec le DOM via des manipulations impératives ou réactives.

2. Pourquoi

JS est indispensable dès que l'état devient dynamique, asynchrone ou interdépendant. Si l'ouverture d'un menu doit déclencher un appel API, ou si l'état d'un composant A doit modifier un composant B situé à l'autre bout de l'arbre DOM, le CSS est impuissant.

3. Comment

A. Syntaxe de base (Manipulation directe)

L'approche classique consiste à basculer une classe.

const toggleBtn = document.querySelector('.toggle');
const menu = document.querySelector('.menu');

toggleBtn.addEventListener('click', () => {
  // L'état est ici "implicite", stocké dans la présence de la classe
  menu.classList.toggle('is-open');
});

B. Cas concret : État synchronisé et typé (Approche Senior)

Dans un contexte professionnel, on préfère séparer la logique d'état du rendu.

type UIState = 'idle' | 'loading' | 'success' | 'error';

class ComponentStateManager {
  private _state: UIState = 'idle';

  // Utilisation d'un setter pour déclencher les effets de bord
  set state(newState: UIState) {
    this._state = newState;
    this.updateDOM();
  }

  get state(): UIState {
    return this._state;
  }

  private updateDOM() {
    const root = document.getElementById('app-root');
    if (!root) return;

    // On utilise des attributs de données (data-attributes) 
    // pour faire le pont avec le CSS
    root.setAttribute('data-ui-state', this._state);
  }
}

const manager = new ComponentStateManager();
manager.state = 'loading'; // Le CSS réagira via [data-ui-state="loading"]

C. Limitations

Le coût majeur du JS est le Layout Thrashing. Si JS lit une propriété géométrique (ex: offsetHeight) puis modifie le style, le navigateur est forcé de recalculer le layout immédiatement, ce qui peut briser la fluidité.

4. Zone de Danger

❌ Erreur commune : Modifier les styles inline (element.style.left = '10px') dans une boucle ou un event scroll. Cela force un recalcul du style à chaque frame sur le fil principal.

✅ Bonne pratique : Utiliser JS pour modifier une variable CSS (--offset) ou une classe, et laisser le moteur CSS gérer l'interpolation et l'animation.

Analyse Comparative et Performance

Le cycle de rendu (Critical Rendering Path)

Pour comprendre l'arbitrage, il faut analyser comment le navigateur traite les changements :

1. JavaScript → Style → Layout → Paint → Composite.
2. CSS (Transitions/Animations) → Composite (si on utilise transform et opacity).

Lorsqu'on utilise JS pour animer un élément en changeant top ou left, on force le navigateur à repasser par les étapes Layout et Paint à chaque frame. C'est extrêmement coûteux.

À l'inverse, une animation CSS utilisant transform: translateX() saute les étapes de Layout et Paint pour aller directement au Composite. Le GPU prend le relais, libérant le CPU.

Tableau de décision technique

Critère	CSS Natif	JavaScript	Verdict
Performance	Maximale (Composite Thread)	Variable (Main Thread)	CSS ≫ JS
Complexité Logique	Très limitée	Illimitée	JS ≫ CSS
Accessibilité	Native (si bien utilisé)	Manuelle (ARIA)	Égalité
Persistance	Aucune	LocalStorage / API / State	JS ≫ CSS
Débogage	Inspecteur CSS	Debugger JS / Redux DevTools	JS ≫ CSS

L'Approche Hybride : Le Pont des Variables CSS

La stratégie la plus robuste pour un profil senior est l'approche hybride. On utilise JS pour la logique de décision et CSS pour la représentation visuelle.

Le vecteur de communication privilégié est la CSS Custom Property (Variable CSS).

// JS : Calcule la position de la souris
window.addEventListener('mousemove', (e) => {
  const x = e.clientX;
  const y = e.clientY;
  
  // On injecte la donnée brute dans le CSS
  document.documentElement.style.setProperty('--mouse-x', `${x}px`);
  document.documentElement.style.setProperty('--mouse-y', `${y}px`);
});

/* CSS : Utilise la donnée pour un effet visuel complexe */
.cursor-follower {
  position: fixed;
  left: var(--mouse-x);
  top: var(--mouse-y);
  transform: translate(-50%, -50%);
  pointer-events: none;
  transition: transform 0.1s ease-out; /* Lissage géré par le moteur CSS */
}

Dans cet exemple, JS ne gère pas le style, il fournit une donnée. Le CSS gère le rendu et l'optimisation.

Questions clés

1. Pourquoi :has() change-t-il la donne pour l'arbitrage CSS vs JS ?

Découvrir la réponse

Avant :has(), le CSS ne pouvait pas remonter dans l'arbre DOM. Pour modifier un parent en fonction de l'état d'un enfant, JS était obligatoire. Désormais, on peut créer des interfaces complexes (comme des formulaires dont le style de conteneur change selon la validité des champs) sans JS, réduisant ainsi la charge du fil principal.

2. Qu'est-ce que le "Layout Thrashing" et comment l'éviter ?

Découvrir la réponse

C'est un cycle de lectures et d'écritures répétées dans le DOM qui force le navigateur à recalculer le layout plusieurs fois par frame. On l'évite en regroupant toutes les lectures d'abord, puis toutes les écritures, ou mieux, en déléguant les modifications visuelles à des classes CSS ou des variables CSS.

3. Quand est-il formellement déconseillé d'utiliser le CSS pour l'état ?

Découvrir la réponse

Dès que l'état doit être synchronisé avec un serveur, partagé entre des composants non liés hiérarchiquement, ou lorsqu'il nécessite une validation logique complexe (ex: "Si l'utilisateur est administrateur ET que le champ A est rempli ET que la date est passée").

4. Quel est l'impact d'une animation JS sur le "Main Thread" ?

Découvrir la réponse

Une animation JS s'exécute sur le fil principal. Si ce fil est occupé par l'exécution d'un script lourd (ex: parsing d'un gros JSON), l'animation va "saccader" (dropped frames), car le navigateur ne pourra pas mettre à jour le style à temps pour la prochaine frame.

Mise en pratique

Exercice 1 : Reproduction guidée (Niveau : Facile)

Créez un composant "Accordéon" purement CSS.

• L'état d'ouverture doit être géré par un élément <input type="checkbox"> caché.
• Le contenu doit être masqué par défaut et s'afficher avec une transition fluide lors du check.
• Utilisez le sélecteur + ou ~ pour lier l'input au contenu.

Découvrir la solution commentée

<div class="accordion">
  <input type="checkbox" id="acc1" class="acc-input" />
  <label for="acc1" class="acc-label">Cliquez pour déplier</label>
  <div class="acc-content">
    <p>Contenu révélé sans JavaScript !</p>
  </div>
</div>

<style>
.acc-input {
  display: none; /* On cache l'input, on garde son état */
}

.acc-label {
  display: block;
  cursor: pointer;
  background: #eee;
  padding: 10px;
}

.acc-content {
  max-height: 0;
  overflow: hidden;
  transition: max-height 0.3s ease-out;
  background: #fafafa;
}

/* L'état : quand l'input est coché, on cible le frère .acc-content */
.acc-input:checked + .acc-label + .acc-content {
  max-height: 200px;
}
</style>

Exercice 2 : Adaptation hybride (Niveau : Intermédiaire)

Implémentez un système de "Thème Dynamique" (Light/Dark/Custom).

• Utilisez JS pour permettre à l'utilisateur de choisir une couleur d'accentuation via un <input type="color">.
• Cette couleur doit être appliquée à tous les boutons et liens du site via une variable CSS.
• L'état "Dark/Light" doit être géré par une classe sur le <body>.

Découvrir la solution commentée

<body class="theme-light">
  <button id="theme-toggle">Toggle Dark Mode</button>
  <input type="color" id="color-picker" value="#007bff" />
  <button class="btn">Bouton Test</button>
</body>

<style>
:root {
  --accent-color: #007bff;
  --bg-color: white;
  --text-color: black;
}

body.theme-dark {
  --bg-color: #222;
  --text-color: white;
}

body {
  background-color: var(--bg-color);
  color: var(--text-color);
}

.btn {
  background-color: var(--accent-color);
  color: white;
  border: none;
  padding: 10px 20px;
}
</style>

<script>
const toggle = document.getElementById('theme-toggle');
const picker = document.getElementById('color-picker');

// Gestion de l'état binaire (Dark/Light) via classe
toggle.addEventListener('click', () => {
  document.body.classList.toggle('theme-dark');
});

// Gestion de l'état continu (Couleur) via Variable CSS
picker.addEventListener('input', (e) => {
  document.documentElement.style.setProperty('--accent-color', e.target.value);
});
</script>

Exercice 3 : Conception Senior (Niveau : Difficile)

Concevez un "Dashboard de Filtres" où :

1. Plusieurs filtres (checkboxes) peuvent être activés.
2. Si au moins un filtre est actif, un bouton "Réinitialiser" doit apparaître avec une animation d'entrée.
3. Si tous les filtres sont activés, le fond de la section doit changer de couleur.
4. Contrainte : Le bouton "Réinitialiser" doit être géré en CSS pur (via :has()), mais l'action de réinitialisation (décocher tout) doit être gérée en JS.

Découvrir la solution commentée

<div class="filter-container">
  <div class="filters">
    <label><input type="checkbox" class="filter-opt" /> Option A</label>
    <label><input type="checkbox" class="filter-opt" /> Option B</label>
    <label><input type="checkbox" class="filter-opt" /> Option C</label>
  </div>
  
  <button id="reset-btn" class="reset-btn">Réinitialiser</button>
</div>

<style>
.filter-container {
  padding: 20px;
  border: 1px solid #ccc;
  transition: background 0.3s;
}

/* 1. Si au moins un filtre est coché, on affiche le bouton */
.reset-btn {
  opacity: 0;
  pointer-events: none;
  transition: opacity 0.3s;
}

.filter-container:has(.filter-opt:checked) .reset-btn {
  opacity: 1;
  pointer-events: all;
}

/* 2. Si TOUS les filtres sont cochés (Logique CSS complexe) */
/* Note: On simule "Tous" en vérifiant que personne n'est décoché */
.filter-container:not(:has(.filter-opt:not(:checked))) {
  background-color: #e0f7fa;
}
</style>

<script>
const resetBtn = document.getElementById('reset-btn');
const checkboxes = document.querySelectorAll('.filter-opt');

// L'action est impérative (JS), car on modifie plusieurs états d'un coup
resetBtn.addEventListener('click', () => {
  checkboxes.forEach(cb => cb.checked = false);
});
</script>