Maîtriser parfaitement la manipulation du DOM en JavaScript vanilla

• Cet article traite de la maîtrise de la manipulation du Document Object Model (DOM) avec du JavaScript vanilla.
• Il souligne l’importance de comprendre l’API DOM du navigateur pour le développement web, malgré l’utilisation d’outils modernes comme Angular, VueJS, React, Solid et Svelte.
• L’auteur propose une collection de ressources comprenant les API natives du navigateur, des exemples faciles à comprendre, des démos en temps réel, des conseils et bonnes pratiques, des cas d’usage concrets, ainsi que la compatibilité avec les navigateurs modernes et Internet Explorer.
• Ces ressources sont réparties en trois niveaux : débutant, intermédiaire et avancé.
• Le niveau débutant inclut des tâches comme changer dynamiquement le favicon selon la préférence de schéma de couleurs de l’utilisateur, calculer le temps de lecture d’une page web et mettre à jour dynamiquement les variables racine CSS.
• Le niveau intermédiaire comprend des tâches comme supprimer l’indentation dans une zone de texte avec la combinaison de touches Shift+Tab, passer en mode plein écran et créer un champ numérique à incrémentation.
• Le niveau avancé inclut des tâches comme créer un curseur personnalisé, assainir des chaînes HTML et créer une barre de défilement personnalisée.
• L’auteur partage aussi des conseils pour éviter les décalages de mise en page à l’ouverture d’une fenêtre modale, ou encore pour obtenir le rectangle englobant de nœuds de texte.
• L’article se termine par une invitation à s’abonner à la newsletter de l’auteur consacrée aux contenus techniques frontend.

[GN⁺]

Avis de Hacker News

• La liste d’exemples est excellente, et il suffit d’en parcourir quelques-uns pour être frappé par le soin et le niveau de détail
  Quand on quitte une plateforme comme React pour une implémentation plus petite et minimaliste, on se retrouve souvent bloqué sur la façon de gérer des patterns complexes en JS standard ; puis, en regardant le code, on se dit parfois : « c’est bien plus simple que de passer une foule de propriétés à une énorme bibliothèque »

  • J’ai eu une prise de conscience similaire après 3 ou 4 mises à jour majeures de RiotJS
    Même un framework JS minimaliste peut facilement finir en monstre de rustines à base de hooks, d’événements et d’effets de bord quand des demandes de fonctionnalités apparemment innocentes s’accumulent
    Aujourd’hui, je n’utilise même plus jQuery, et j’emploie des choses comme les modules ES pour organiser le code, mais sans avoir besoin de lancer une commande npm. Ce n’est pas un truc à embarquer comme dépendance vendor, c’est un standard global du navigateur
    Ces temps-ci, je consulte MDN comme une bible. Si on lui fait confiance et qu’on le suit, il vous emmène presque jusqu’au bout, alors que les frameworks finissent plutôt par vous freiner à partir d’un certain point. Il y a 5 ans, ce n’était pas encore à ce niveau, mais les API des navigateurs ont rapidement convergé vers des briques de base puissantes et cohérentes comme les modules, flexbox et grid
  • Les exemples de l’article d’origine ne sont pas vraiment en concurrence avec les frameworks client web. Le problème général que résolvent les frameworks, c’est la gestion d’état et la mise à jour de l’UI quand l’état change
    Par exemple, la plupart des exemples de l’article ressemblent plutôt à du code qu’il faudrait écrire soi-même même en utilisant React

• Je développe en side project une sorte de « vim pour web designers », qui n’a pas encore de nom. Comme Webflow, il permet de créer des sites ou des composants dans le navigateur, mais tout est piloté par un langage de commandes
  Au début, j’étais décidé à le faire sans framework. Je fais ça depuis 2009 et j’utilise JS depuis longtemps, bien avant de toucher aux frameworks, donc je pensais que les API DOM natives suffiraient
  Mais déplacer des données vers et depuis le DOM était tellement fastidieux et source d’erreurs que, pour préserver ma santé mentale, j’ai fini par écrire moi-même un mini-framework. C’est là que je me suis souvenu pourquoi on avait commencé à utiliser des frameworks au départ. Au final, on utilise un framework sous une forme ou une autre ; la seule différence est de savoir s’il est sur mesure et fait maison, ou s’il s’agit d’un standard de fait créé par la communauté
  Pour un site avec peu d’interactions, le DOM natif est très bien, et la plupart des sites qui utilisent React n’en ont probablement pas vraiment besoin. Mais dès qu’un produit a un peu de nuance ou de complexité, je préfère utiliser un framework et éviter les galères. Je suis finalement passé à Svelte, et j’en suis bien plus satisfait

  • Les projets ultra-minimalistes finissent par réimplémenter la moitié de jquery ou de lodash. Il est beaucoup plus simple de trouver une bonne bibliothèque comme ramda, avec un bon tree shaking, et de l’utiliser avec parcimonie
  • La formule « si tu ne choisis pas de framework, tu finiras par en créer un » est parfaitement juste
  • Ici, il s’agit de construire une application, donc rien qu’à la description, on peut supposer qu’il vaut mieux encapsuler les interactions avec le DOM
    Pour un site web qui a besoin d’interactions, la manipulation du DOM peut être un meilleur choix parce qu’elle s’appuie sur une technologie plus fondamentale et plus universelle, avec un processus de build léger ou inexistant, une exécution rapide, et un comportement explicite
    Il y a bien sûr beaucoup de zones grises, mais ce cas entre exactement dans la catégorie où un framework apporte un bénéfice
  • Aujourd’hui, SvelteKit est centré sur le SSR, et Svelte lui-même n’a pas de routeur client par défaut. J’ai essayé d’utiliser Svelte pour une application monopage en CSR, puis j’ai abandonné

• Se contenter de value.startsWith('javascript:') crée une vulnérabilité. Une URL peut être précédée d’espaces arbitraires, donc il faut au minimum value.trim().startsWith('javascript:')
  Cela dit, je pense qu’une liste d’autorisation vaut mieux qu’une liste de blocage. N’autoriser que http:, https: et, si nécessaire, mailto:, ftp:, sftp: ; et peut-être les URL relatives qui commencent par /
  Mais comme il faut traiter correctement tous les attributs susceptibles d’être des URL, il vaut sans doute mieux finir par n’autoriser que certains tags et leurs attributs

  • Si vous n’avez pas besoin de prendre en charge de très vieux navigateurs [1], le plus simple est de laisser le navigateur parser les URL. Par exemple, on peut faire ['http:', 'https:', 'mailto:', 'tel:'].includes(new URL(value, location.origin).protocol)
    [1] https://caniuse.com/url
  • Il semble qu’il soit question ici de la page « Sanitize HTML strings » de cet article : https://phuoc.ng/collection/html-dom/sanitize-html-strings/
    Cet article ne devrait pas donner l’impression que la sanitisation HTML est aussi simple. Il mentionne bien https://github.com/cure53/DOMPurify vers la fin, mais il devrait dire beaucoup plus fermement de ne pas essayer d’écrire ce genre de chose soi-même et recommander uniquement DOMPurify
    J’ai ouvert une issue à ce sujet : https://github.com/phuocng/html-dom/issues/281

• Cela ressemble à une liste utile à connaître, et même si je ne l’ai pas entièrement parcourue, ce que j’ai vu jusqu’ici semble correct
  En cliquant sur le premier exemple, j’ai remarqué qu’il exécute inutilement deux fois window.matchMedia('(prefers-color-scheme: dark)')
  Si setFavicon doit servir de callback d’écouteur d’événement, il suffit d’utiliser event.matches depuis le paramètre event passé au callback
  Personnellement, je préfère le faire côté HTML, car cela prend aussi en charge les utilisateurs qui ont désactivé JS
  https://phuoc.ng/collection/html-dom/change-the-favicon-dyna...

  • Le faire en HTML permet aussi d’éviter le bref flash de contenu du mauvais thème. On peut appliquer la même approche à la méta theme-color, une fonctionnalité excellente mais peu utilisée, même par les développeurs de PWA soucieux du détail

• La technique de « textarea à expansion automatique » est en train de vieillir à cause de la nouvelle propriété CSS form-sizing
  https://chriscoyier.net/2023/09/29/css-solves-auto-expanding...
  Même sans utiliser cette nouvelle propriété CSS, ajuster la height d’un élément n’est pas idéal et peut provoquer des saccades
  Une meilleure approche consiste à utiliser un élément miroir caché
  https://css-tricks.com/the-cleanest-trick-for-autogrowing-te...

• Pas mal de choses ici utilisent des API anciennes et maladroites alors qu’il existe de meilleures API natives
  Par exemple, « remplacer un élément » est écrit avec ele.parentNode.replaceChild(newEle, ele);, mais si vous ne ciblez pas Chrome < 54, Firefox < 49 ou Safari < 10, vous pouvez simplement utiliser ele.replaceWith(newEle)
  replaceWith permet aussi de remplacer un nœud par plusieurs nœuds ou par du texte
  De même, pour « parcourir une NodeList », il est conseillé de convertir en tableau avec l’opérateur de décomposition puis d’utiliser forEach, alors qu’un simple for (let ele of nodelist) ... suffit

  • Il faut garder à l’esprit qu’une NodeList peut être un objet live. Si vous modifiez cette liste pendant l’itération, vous pouvez obtenir des résultats inattendus

• Bien. Mis en favoris. Dans le même esprit, il y a aussi cette bonne ressource : https://youmightnotneedjquery.com/
  Je ne fais pas souvent du web, mais chaque fois que j’en fais, la surabondance de frameworks dans ce domaine me coupe complètement l’envie. Qu’un nouveau projet React démarre avec des centaines de dépendances est hors de contrôle, et le poids de cette complexité est stupéfiant
  À l’inverse, les technologies de navigateur cross-platform intégrées sont plus puissantes que jamais, et la quantité de code nécessaire pour des tâches courantes n’est pas si élevée
  Développeurs frontend, vous allez bien ?

  • Je n’aime pas particulièrement React ni npm, mais je pense que certains frameworks ont toujours leur place, car ils apportent des choses utiles que les API DOM pures ne fournissent pas
    Par exemple, la gestion de l’état applicatif et le routage sont de gros morceaux qu’il faut implémenter soi-même si l’on n’utilise que les API DOM pures
    Selon la complexité de l’application, ce n’est pas forcément grand-chose, mais dès qu’on dépasse une appli basique, la valeur de ces fonctionnalités supplémentaires augmente vite. Cela dit, si vous utilisez quelque chose qui nécessite NPM, ça devient pénible
  • Dans le même esprit, une autre excellente ressource est le très bon https://javascript.info/
    En tant que développeur frontend qui apprécie la plateforme de base et ses fonctionnalités, je suis heureux de voir arriver de bonnes choses comme le CSS imbriqué, les container queries et l’expérience JS globalement améliorée depuis ES6
    En même temps, je suis surpris de voir autant de gens utiliser des composants même pour des détails comme un bouton ou du texte en gras
    J’aime les frameworks en eux-mêmes, mais le marketing de nombreux frameworks et bibliothèques s’appuie sur l’idée que le CSS et la manipulation du DOM pur sont incroyablement difficiles, et que récupérer n’importe quel paquet sur NPM est non seulement plus rapide et plus facile, mais aussi plus professionnel
  • Je suis d’accord pour dire que c’est hors de contrôle. Mais depuis un an, je suis passé dans une équipe plateforme et j’ai commencé à manipuler des outils côté DevOps pour la première fois, et cette complexité n’a rien à envier au frontend
    Rien qu’avec Kubernetes, Helm, Terraform, CircleCI, la quantité de jargon empilé en couches est absurde
  • Je me demande si vous avez déjà fait quelque chose de non trivial avec ces « technologies cross-platform puissantes ». Et React n’est pas la seule option

• J’ai vraiment été surpris quand j’ai appris que plusieurs fonctions DOM renvoyaient des live HTMLCollection qui se mettent automatiquement à jour
  Je me demande à quel point cette fonctionnalité a été activement utilisée dans du code de production réel, avant la frénésie des frameworks ou autour du moment où le développement sans framework a commencé à regagner un peu en popularité

• Ce qui est ancien redevient nouveau. Mon premier poste frontend, en 1999, consistait à créer des applications web
  Glisser-déposer dans une vue arborescente, édition au clic, fonctionnalités sophistiquées proches d’une application monopage : tout était fait en JS « Vanilla »
  La partie la plus difficile était de concilier les différences entre Netscape et Internet Explorer

  • Je me demande comment l’état et ses modifications étaient gérés
    Pourquoi a-t-on l’impression qu’on ne sait plus faire ça aujourd’hui ;]

• Ma fonctionnalité JavaScript pur préférée ces temps-ci est Element.insertAdjacentHTML, présente depuis l’époque de Chrome 1.0 et d’IE
  Dire qu’elle est utile, surtout avec les chaînes multilignes utilisant les backticks, est un euphémisme. J’ai du mal à croire qu’elle existe depuis si longtemps et que je ne l’ai découverte qu’il y a environ un an
  insertAdjacentHTML(position, text) analyse le texte donné comme du HTML ou du XML, puis insère les nœuds obtenus à l’emplacement indiqué dans l’arbre DOM
  En DOM pur, auparavant, il fallait créer un élément li, créer un élément a, l’ajouter comme enfant, définir l’attribut href, définir la valeur du texte, puis l’insérer dans le ul. Ou alors construire une grosse chaîne et l’injecter avec innerHTML, et modifier une liste existante était encore plus pénible et verbeux

  1. https://developer.mozilla.org/en-US/docs/Web/API/Element/ins...