Pourquoi les développeurs web boudent les APIs du navigateur
En bref
- L'article examine pourquoi les développeurs continuent de construire leurs propres solutions JavaScript alors que le navigateur offre des APIs équivalentes. Historiquement, les navigateurs rattrapaient leur retard ; aujourd'hui, c'est par habitude (ecosystem npm), meilleure documentation des bibliothèques, et surtout parce que rouler sa propre solution est plus ludique et pédagogue. Le débat HN soulève que c'est moins une question de fun que de limitations réelles des APIs natives, de fragmentation cross-browser, et de besoins UX impossibles à satisfaire avec le seul HTML/CSS.
Ce que dit la source
Nolan Lawson argue que les développeurs web ont historiquement eu raison de construire leurs propres solutions : les navigateurs jouaient long-temps les rattrapers, et les frameworks comme React comblaient des vides cruciaux. Mais aujourd'hui, avec les navigateurs evergreen et des standards robustes, cette habitude persiste surtout par inertie (familiarité avec npm), meilleure documentation des packages, et un facteur psychologique : construire soi-même est plus enrichissant pédagogiquement et laisse plus de contrôle créatif. L'auteur reconnaît que cette dynamique l'a d'ailleurs poussé à devenir expert en standards (PouchDB, IndexedDB) précisément parce qu'il remplissait des vides APIs.
- Les navigateurs ont longtemps laissé des vides que jQuery, React et autres ont comblés, créant une habitude durable même maintenant que les standards existent.
- La documentation des packages npm (README détaillé, exemples, tutoriels) a historiquement éclipsé celle du web platform, scattered entre blogs, StackOverflow et CSS-Tricks.
- Pour certains développeurs, la construction personnalisée est pédagogiquement plus enrichissante et offre une compréhension plus profonde que de consommer une API boîte noire.
- La fragmentation des implémentations natives persiste : <datalist> sur la plupart des navigateurs est inutilisable ; <dialog> n'autorise en Firefox que les fade-in, pas de fade-out ; <input type=datetime-local> pose des soucis d'accessibilité différents selon le lecteur d'écran.
- Les besoins UX des Top 100 sites dépassent systématiquement ce que le platform propose : date/time pickers personnalisés, combobox avec recherche accessible, validation custom sur les champs numériques.
- Web Components souffrent d'une adoption quasi inexistante sans wrapper (Lit, etc.) ; le Shadow DOM reste contre-intuitif et les retours de frustration sur HN sont récurrents.
- La causalité est inversée : les patterns établis par les devs (scroll-driven animations, etc.) inspirent ensuite les standards, plutôt que l'inverse ; c'est un effet de désir paths.
Dans les commentaires
Débat partagé et nuancé. Lawson tente une compréhension bienveillante, mais les commentateurs récusent sévèrement la prémisse 'l'APIs native est meilleure' en pointant des limitations authentiques et des cas d'usage réels non couverts. Le fil démonte aussi l'idée que c'est une question de 'fun', en soulignant que c'est surtout une réaction rationnelle aux fragmentations cross-browser et aux exigences UX irréalistes.
- Plusieurs commentateurs contestent fermement que les APIs natives soient systématiquement meilleures : <datalist>, <input datetime>, <dialog> et Web Components souffrent de limitations réelles (mauvaise implémentation cross-browser, animations impossibles, accessibilité cassée selon l'OS/lecteur d'écran) qui forcent à rouler du custom.
- Un commentaire note que les designers UX et le marketing refusent à peu près toujours ce que le platform offre natif ; les Top 100 sites utilisent tous des date/time pickers custom, ce qui rend impossible de 'juste utiliser' <input> si tu veux être compétitif.
- Plusieurs relèvent que la fragmentation cross-browser persiste : certaines features ne marchent bien que sur Blink/V8, d'autres pas sur Firefox, menaçant la viabilité d'une solution unique.
- Un développeur rapporte qu'après avoir remplacé 100kb de React par <input type=datetime-local> pour l'accessibilité, un utilisateur Firefox+NVDA a demandé l'ancien composant dans les 24h, illustrant un dilemme réel entre théorie et réalité de terrain.
- L'argument 'c'est plus fun' est rejeté : l'auteur minimiserait la frustration historique et légitime due à des APIs réellement mauvaises ; React n'a jamais été 'fun', il a rendu possible ce qui était sinon cumbersome avec le DOM.
- Web Components sont largement critiqués comme mal dessinés (Shadow DOM opaque, pas de CSS reset, API weird) ; l'adoption quasi zéro en pur WC (vs Lit wrapper) le prouve.
Notre lecture
L'article reste utile pour sa tentative de fairness, mais le débat HN le corrige sur le terrain : ce n'est pas une question d'inertie ou de psychologie ludique. Les limitations réelles des APIs natives (implémentations broken, fragmentation cross-browser, exigences UX non couvertes) justifient rationnellement de construire du custom. Là où l'article a raison : l'habitude joue aussi un rôle, et la documentation du platform s'est améliorée. Mais le 'use the platform' restera un idéal aspirationnel tant que les navigateurs ne combleront pas les écarts d'implémentation et que les UX designers continueront d'exiger du custom. À suivre : évoluent les standards assez vite pour rejoindre ce qui est réellement utilisé.