Contexte historique

Jusqu’au début des années 2020, les navigateurs n’étaient pas evergreen : les versions d’Internet Explorer 6 persistaient longtemps, obligeant les équipes à supporter des lacunes fonctionnelles avec des polyfills ou des bibliothèques tierces comme jQuery. La lenteur du cycle de mise à jour – parfois plusieurs années entre deux versions majeures – créait un web lumpy où le code JavaScript était souvent la seule solution fiable.

Lorsque les navigateurs sont devenus evergreen (Safari se met à jour environ sept fois par an, selon l’auteur), les API natives ont rattrapé les besoins couverts par les bibliothèques. Pourtant, l’habitude de « chercher un composant sur npm » persiste, car les développeurs ont déjà intégré ces flux de travail dans leurs pipelines.

Ergonomie des bibliothèques vs. API natives

Les composants React publiés sur npm offrent une interface déclarative qui masque les appels DOM bruts. Par exemple, un composant de liste virtuelle utilise directement document.createElement et appendChild pour optimiser le rendu, mais expose un <VirtualList /> simple à consommer. Cette couche d’abstraction réduit le coût cognitif : le développeur ne doit pas connaître les subtilités de position: sticky ou du calcul de hauteur dynamique.

En revanche, l’API native <dialog> fournit déjà la gestion du focus, du clavier et du masquage du fond. Son utilisation se résume à quelques lignes HTML et JavaScript, comme illustré ci‑dessous :

<dialog id="myDialog">
  <p>Contenu du dialogue</p>
  <button onclick="this.closest('dialog').close()">Fermer</button>
</dialog>

  document.getElementById('myDialog').showModal();

Malgré cette simplicité, de nombreux développeurs préfèrent ré‑implémenter la logique avec des div et du CSS, car ils maîtrisent déjà ces primitives et perçoivent la solution native comme « icky ».

Documentation et visibilité

MDN et web.dev sont devenus les référentiels officiels, mais avant cela la documentation du web était fragmentée entre blogs, StackOverflow et sites comme CSS‑Tricks. Un article de CSS‑Tricks présentant Dragula (bibliothèque de drag‑and‑drop) était souvent plus accessible qu’une page MDN décrivant l’API native DataTransfer. La présence de README détaillés et de démonstrations interactives sur les dépôts npm crée un biais de visibilité qui pousse les développeurs à choisir la bibliothèque plutôt que l’API du navigateur.

Ce phénomène n’est pas purement technique : il reflète aussi la dynamique de la communauté. Les auteurs de bibliothèques publient des tutoriels, des vidéos et des badges de build, ce qui génère un effet de réseau difficile à reproduire pour les spécifications du W3C.

Impacts sur performance et accessibilité

Lorsque le même problème est résolu avec du JavaScript pur, le poids du bundle augmente et le temps d’exécution s’allonge, surtout sur les appareils mobiles. L’API native position: sticky est exécutée directement par le moteur de rendu, garantissant une fluidité supérieure à une implémentation JavaScript qui doit écouter le scroll et mettre à jour les styles à chaque frame.

En matière d’accessibilité, les composants natifs intègrent déjà des comportements attendus (gestion du focus, annonces ARIA). Une implémentation maison doit reproduire ces mécanismes, ce qui augmente le risque d’erreurs – par exemple, oublier de restaurer le focus après la fermeture d’un dialogue. Ainsi, même si la construction « DIY » peut être pédagogique, elle introduit des vulnérabilités fonctionnelles qui ne sont pas présentes dans les API natives.