Dans l'article sur les micro-interactions, j'écrivais que transform et opacity s'animent sur le thread de composition, donc même une page lourde ne devrait pas saccader l'animation d'un bouton. C'est toujours vrai – avec une réserve que cet article-là passait sous silence : si le thread principal est bloqué par une longue tâche JS, l'animation risque de ne jamais avoir la chance de démarrer, car le handler de clic lui-même attend dans la file. L'INP est la métrique qui mesure exactement cet écart – et scheduler.yield() est l'un des rares moyens de réellement le combler.
Une liste de mille commentaires se rend lentement, alors vous vous tournez vers react-window – et en échange d'un scroll fluide, vous perdez Ctrl+F, l'impression de la page et en partie la navigation du lecteur d'écran, car les éléments hors de la fenêtre cessent d'exister physiquement dans le DOM. content-visibility résout le même problème autrement : les éléments restent dans le DOM, le navigateur se contente de sauter pour eux le travail coûteux de mise en page et de peinture tant qu'ils ne sont pas proches de la zone visible – et, chose surprenante, il peut les révéler temporairement quand vous y cherchez du texte.
Dans l'article sur l'accessibilité, une modale en display:none qui restait présente dans l'arbre d'accessibilité illustrait une erreur née d'une modale construite à la main sur des divs. La vraie question est : pourquoi fallait-il la construire à la main ? J'examine ce que le <dialog> natif et l'attribut popover offrent gratuitement – top layer, piège à focus, light dismiss – et où ces deux mécanismes divergent suffisamment pour que les confondre soit le chemin le plus court vers une interface inaccessible.
Le bouton « J'aime » réagit instantanément, le cœur se remplit, le compteur augmente – avant même que le serveur ait répondu. Ce n'est pas l'illusion de rapidité de l'article sur les micro-interactions, c'est quelque chose qui va plus loin : l'interface affiche un état qui n'existe pas encore, en supposant qu'il existera bientôt. J'examine comment construire cela en toute sécurité – avec un vrai retour en arrière quand l'hypothèse ne se vérifie pas – et pourquoi un setState manuel plus un catch est une version dégradée de ce qu'offre useOptimistic.
« use server » ressemble à du sucre syntaxique pour un fetch vers une API route – et c'est précisément pour cela que la plupart des implémentations le traitent comme un simple appel de fonction. C'est une erreur aux conséquences concrètes : chaque fonction marquée « use server » devient un point d'entrée public sur le réseau, et un formulaire construit sur ce mécanisme fonctionne même avant que le JavaScript ait eu le temps de se charger. J'examine ce qui se passe vraiment derrière cette directive, et où se cachent les pièges qu'on ne voit pas au premier coup d'œil dans la documentation.
Un HTML correct n'est qu'un point de départ. Découvrez comment fonctionne vraiment l'arbre d'accessibilité, pourquoi ARIA fait plus de mal que de bien plus souvent qu'on ne le croit, et construisons ensemble un vrai accordéon, une live region et la gestion du focus dans Next.js.
