Remplacer JavaScript par du HTML seul

• Présentation de méthodes récentes pour remplacer dans le web des fonctionnalités dépendantes de JS par du HTML/CSS
• Mise en œuvre d’accordéons, d’autocomplétion, de modales et de navigation hors écran à l’aide d’éléments standard comme details·summary, datalist et popover
• Cette approche réduit le téléchargement, l’évaluation et l’usage mémoire, ce qui améliore les performances et l’expérience utilisateur
• Pour chaque fonctionnalité, des exemples CodePen, documents MDN et informations de compatibilité navigateur sont fournis
• Il faut réserver JS aux zones réellement nécessaires et exploiter activement les fonctionnalités avancées de HTML/CSS

---

Remplacer des fonctionnalités JS par HTML et CSS

• Pendant longtemps, JavaScript a pris en charge des fonctionnalités impossibles à implémenter avec HTML et CSS
  • Mais à mesure que HTML et CSS se sont enrichis, certaines fonctionnalités JS peuvent être remplacées par des technologies web natives
• Comme JS doit être téléchargé, décompressé, évalué et conservé en mémoire, il est plus efficace de basculer vers HTML/CSS chaque fois que c’est possible
• L’idée proposée est de concentrer JS sur la logique complexe et de confier les contrôles d’interface simples à HTML/CSS

Accordéon / panneau de contenu extensible

• Les éléments details et summary permettent d’implémenter un accordéon sans JS
  • Le contenu peut être ouvert et fermé par clic, et l’état par défaut se définit avec l’attribut open
  • En utilisant le même attribut name, un seul panneau peut rester ouvert
• Il est aussi possible de le styliser avec CSS ou de piloter l’ouverture/fermeture avec JS
• Ressources associées : documentation MDN sur details, exemple CodePen, tableau de compatibilité navigateur

Champ de saisie avec suggestions d’autocomplétion

• La combinaison de input et datalist permet de créer une liste déroulante filtrée automatiquement
  • Lors de la saisie, la liste de suggestions est filtrée automatiquement
  • En plus du texte, différents types de saisie comme number ou time sont pris en charge
• Firefox ne prend actuellement en charge que les champs de type texte, et il existe des limites d’accessibilité sur mobile
• Ressources associées : documentation MDN sur datalist, tutoriel SitePoint, tableau de compatibilité navigateur

Modale / popover

• Les attributs popover et popovertarget permettent de créer des modales et popovers sans JS
  • Trois modes sont proposés : auto, hint et manual
  • auto se ferme via un clic à l’extérieur ou avec Échap, tandis que manual ne se ferme que manuellement
• Firefox et iOS ne prennent pas en charge le mode hint
• Ressources associées : documentation MDN sur popover, blog Chrome, exemple CodePen, vidéo sur l’accessibilité

Navigation / contenu hors écran

• La fonctionnalité popover permet aussi d’implémenter un menu de navigation hors écran
  • L’élément nav apporte une sémantique adaptée, et translate en CSS permet de faire entrer ou sortir le menu de l’écran
  • Le menu se ferme lors d’un clic extérieur, et popover="manual" permet de configurer une fermeture manuelle
  • Le pseudo-élément ::backdrop permet d’appliquer un fond semi-transparent
• Ressources associées : API Popover de MDN, blog Chrome, exemple CodePen

Conclusion

• Il faut reconnaître la puissance de JS, mais ne l’utiliser que là où c’est nécessaire
• Les avancées récentes de HTML/CSS ont fait émerger de nombreuses alternatives sans JS
• Davantage d’exemples sont disponibles dans le billet de blog de l’auteur, “Replace JS with No-JS or Lo-JS Options”
• Accent mis sur l’amélioration de l’expérience utilisateur grâce à la réduction de JS et à l’optimisation des performances

[skageektp]

Il est possible d’implémenter un accordéon sans JS avec les éléments ** et **

On dirait qu’il manque une partie du contenu.

[xguru]

Je l’ai corrigé~ !

[shakespeares]

Il y a clairement des limites, et à partir du moment où l’IA est activée… est-ce vraiment nécessaire de faire ce genre de refactoring ?
Est-ce que cela prend en compte des aspects comme le blocage du contenu JS ?

[GN⁺]

Avis sur Hacker News

• Dommage que tous les exemples n’aient pas été mis inline
  À la place de liens CodePen, il aurait été bien plus convaincant d’intégrer directement sur la page des exemples de remplacement en HTML
  • Tout à fait d’accord. Souvent, quand on clique sur un truc comme FooMaker v1.0, il n’y a aucun exemple d’usage courant, seulement des cas limites farfelus
  • Au début, j’ai cru que c’était un article vieux de 25 ans. Les GIF tramés ont un côté totalement rétro
  • Moi aussi, l’absence d’exemples inline m’a frustré, mais si c’est un article invité, je peux le comprendre dans une certaine mesure
• Le potentiel des balises <details> / <summary> est vraiment énorme
  On peut presque tout faire avec, pourtant la plupart des bibliothèques de composants les ignorent
  Pas besoin non plus d’attributs aria, et l’accessibilité est fournie par défaut
  • Avant, le principal défaut était que cmd+f ne trouvait pas le texte dans des details fermés, mais maintenant on peut le gérer avec l’attribut hidden="until-found" et des événements
  • En revanche, la gestion des animations est délicate. Les navigateurs ne prennent pas en charge nativement les transitions sur les changements de display
  • Il existe aussi une fonction où une recherche avec ctrl+f ouvre automatiquement les details
  • <details> fonctionne aussi sur des sites basés sur Markdown comme GitHub. On peut y replier de longs logs pour les publier proprement
  • C’est aussi faisable en pur CSS. Par exemple, dans la documentation Go101, on peut cliquer sur « + » pour développer. Il y a aussi cette démo de panneaux à onglets. De quoi montrer la force de Modern CSS
• L’idée centrale n’est pas tant « no JavaScript » que le fait que HTML gère déjà des fonctionnalités oubliées (formulaires, dialogues, validation, navigation, etc.)
  En écrivant le livre « You Don’t Need JavaScript », j’ai eu le sentiment que JS sert souvent moins à ajouter des fonctions inédites qu’à compléter les capacités existantes de la plateforme
  • J’aimerais voir plus de livres de ce genre. Il faut des ouvrages centrés sur la résolution de problèmes, pas seulement sur l’apprentissage d’un framework
  • À l’époque, le support navigateur était insuffisant, donc les développeurs ont créé des contournements qui ont fini par devenir des standards de fait. Ces derniers temps, le rythme de sortie des fonctionnalités CSS s’accélère, au point que la mise en page masonry est elle aussi entrée en phase expérimentale
• La plupart des fonctionnalités HTML sont excellentes, mais <input> et <datalist> restent insuffisants en usage réel
  Les utilisateurs attendent une tolérance aux fautes de frappe, du texte d’aide et une bonne UX mobile, mais datalist ne répond pas à ces attentes
  • Le plus gênant, c’est qu’on ne peut pas séparer dans datalist le texte affiché et la vraie valeur (value)
  • Dans la plupart des cas, select est plus adapté, mais il n’a pas de fonction de recherche
  • Le style par défaut est beaucoup trop rustique et laid
  • Sur Android, le menu déroulant n’apparaît même pas
  • Comme le comportement varie d’un appareil à l’autre, on finit par ajouter du JS. Avec HTML seul, on tombe dans un enfer de compatibilité
• J’ai récemment passé plusieurs entretiens frontend, et on n’évalue toujours que les compétences JS centrées sur React
  L’usage sémantique de HTML ou l’accessibilité sont presque totalement ignorés
  • Si l’équipe utilise React, quelqu’un qui manipule directement la DOM API peut être éliminé pour inadéquation avec l’équipe
  • Avec un fichier CSS séparé, les composants deviennent bien plus propres. Tailwind n’est pas mauvais, mais je n’aurais pas envie de l’utiliser en entretien
  • En dehors de HN, presque personne ne s’intéresse au purisme HTML
• Le fait de ne mettre que des liens CodePen sans intégrer les exemples directement dans la page me gêne
  Pour un article qui dit « faisons-le uniquement en HTML », dépendre d’un service externe semble contradictoire
  • Personnellement, ça ne me dérange pas. CodePen est pratique pour les signets et la coloration syntaxique. Il y a quand même un risque de pourrissement des liens (link rot)
  • Malgré tout, ça aurait été mieux de proposer à la fois des exemples inline et des liens CodePen
  • Mettre en avant HTML tout en obligeant à charger une interface CodePen de 2 Mo, c’est paradoxal du point de vue UX
• La fonctionnalité de select personnalisable devrait bientôt arriver, et j’en attends beaucoup
  C’est au stage 3 du WHATWG, et cela pourrait remplacer les implémentations JS de menus déroulants, souvent cauchemardesques
  Voir cet article du blog Chrome
• Le HTML pur est familier et confortable, mais il a ses limites pour construire aujourd’hui des webapps fonctionnelles
  J’ai aussi essayé des alternatives comme HTMX ou Phoenix LiveView, mais ce ne sont pas des solutions complètes
  Au final, je me dis qu’accepter le JS moderne est l’option la plus réaliste
  • Même avec juste un peu de JS, on peut aller bien plus loin qu’avec HTML seul. Le vrai problème du web actuel, c’est l’abus de JS qui dégrade fortement l’utilisabilité
  • On a l’impression qu’HTMX est vu comme plus compliqué qu’il ne l’est. En s’appuyant sur l’état serveur et sur hx-select / hx-target, on peut garder les choses simples
  • La balise <marquee> convenait bien pour les défilements horizontaux sur les sites e-commerce, alors qu’aujourd’hui on bricole ça en JS. J’aimerais que HTML prenne en charge davantage de patterns d’interface nativement
  • J’ai gaspillé beaucoup de tokens à essayer de recréer un effet marquee dans React. Ce n’était même pas une boucle parfaite, juste un bricolage d’animation
  • Si vous utilisez Elixir et Phoenix, Gleam peut aussi valoir le détour. Il se compile en JS
• HTML et JS sont des outils aux finalités différentes
  Pour les webapps complexes, JS est indispensable, mais il existe beaucoup de domaines où HTML seul suffit
  • Pour quelque chose comme Google Earth, évidemment qu’il faut du JS, mais je pense qu’un service du niveau de Gmail serait aussi faisable en HTML. Les tendances et le battage médiatique poussés par les éditeurs de navigateurs freinent l’évolution de HTML
  • htmx est dans une relation complémentaire avec JS. L’idée clé, c’est d’échanger de l’hypertexte structuré au lieu de JSON. En pratique, j’ai déjà construit assez vite des applis assez complexes avec htmx + un peu de JS
  • HTML devrait intégrer davantage de fonctions de base. Par exemple, la prise en charge des verbes HTTP, ou de meilleurs contrôles de saisie
  • Beaucoup de sites très chargés en JS pourraient en réalité être remplacés par htmx sans problème. Le choix des outils relève souvent de l’habitude
• Je suis d’accord avec l’idée que « JS n’a pas besoin de gérer les accordéons ou les menus de navigation »
  Mais JS est désormais devenu un outil central de collecte de données et de suivi publicitaire
  Je me demande si, sans JS, les big tech pourraient mettre en place le même niveau de surveillance et de services publicitaires
  Au fond, l’hostilité envers JS ne vient pas seulement d’un problème technique, mais aussi d’une défiance envers l’écosystème publicitaire

[labeldock]

Ce genre de tentative me permet parfois de réfléchir à la question de savoir si je fais de l’overengineering, mais du point de vue du travail réel avec des exigences riches, cela tient davantage du numéro de force.