Construire un frontend robuste grâce à l’amélioration progressive

 (gov.uk)
1 points par GN⁺ 2024-09-30 | 1 commentaires | Partager sur WhatsApp

Comment construire un frontend robuste : l’amélioration progressive

  • Commencer par le HTML

    • Les services publics doivent rester fonctionnels avec le seul HTML
    • La couche HTML est tolérante aux pannes, ce qui permet un fonctionnement même sur d’anciens navigateurs
    • Il faut utiliser un balisage sémantique correct et structurer le document de façon logique

  • Utiliser le CSS

    • Le CSS peut être utilisé pour styliser le service
    • La couche CSS est tolérante aux pannes, car elle peut ignorer des déclarations individuelles
    • Il faut éviter les techniques comme le CSS-in-JS

  • Utiliser JavaScript

    • JavaScript sert à ajouter des éléments interactifs
    • La couche JavaScript n’est pas tolérante aux pannes et peut produire des erreurs
    • La compatibilité peut être améliorée via la détection de fonctionnalités des API navigateur, l’ajout de polyfills, la transpilation, etc.
    • JavaScript doit jouer un rôle complémentaire au HTML et au CSS

  • Alternatives à JavaScript

    • Il faut envisager des solutions simples capables de répondre aux besoins des utilisateurs sans JavaScript
    • Parmi les alternatives : l’affichage de tableaux de données, l’export de données, ou le pré-rendu de graphiques sous forme d’images

  • Utiliser un framework JavaScript côté client

    • Il faut éviter d’utiliser un framework sauf en cas d’interface utilisateur complexe
    • L’usage d’un framework peut entraîner une augmentation de la taille de la base de code, des problèmes de performance et une dépendance à du code tiers
    • Si un framework est utilisé, chaque interface utilisateur doit être conçue comme un composant distinct

  • Pourquoi le CSS ou JavaScript ne se charge pas ou ne s’exécute pas

    • Cela peut être dû à des erreurs réseau, des extensions de navigateur, une indisponibilité d’un fournisseur tiers, un échec de résolution DNS ou des bugs causés par une mise à jour du navigateur
    • Certains utilisateurs peuvent aussi désactiver volontairement des fonctionnalités du navigateur

  • Application monopage (SPA)

    • Il ne faut pas construire un service sous forme d’application monopage
    • Les SPA nuisent à l’accessibilité et peuvent provoquer des problèmes de gestion du focus lors de la navigation entre les pages, ainsi que l’impossibilité d’utiliser les boutons précédent/suivant

  • Tester le service

    • Les composants qui dépendent fortement de JavaScript ou d’un framework JavaScript doivent fonctionner sur différents navigateurs et appareils
    • Des tests d’accessibilité sont nécessaires

  • Études de cas et guides associés

    • Pourquoi utiliser l’amélioration progressive
    • Concevoir pour une diversité d’appareils
    • Comment tester les performances frontend
    • Comprendre les WCAG 2.2

Le résumé de GN⁺

  • L’amélioration progressive est une méthode de construction de sites web qui suit l’ordre HTML, CSS, puis JavaScript
  • Cette approche améliore la tolérance aux pannes du service et lui permet de fonctionner sur différents navigateurs et appareils
  • JavaScript doit jouer un rôle complémentaire, et des solutions alternatives doivent être envisagées
  • Les applications monopages sont à éviter en raison de leurs problèmes d’accessibilité
  • Les tests du service doivent garantir l’accessibilité dans des environnements variés

À lire aussi

1 commentaires

 
GN⁺ 2024-09-30
Avis sur Hacker News

  • Lorsqu’on utilise un framework JavaScript, il faut pouvoir démontrer quel bénéfice concret il apporte à l’utilisateur

    • Si une application peut fonctionner hors ligne comme une application de bureau, il est préférable d’en faire une single-page application (SPA)
    • Exemples : Photopea, Google Docs/Sheets, tldraw
    • Si une application nécessite une connexion Internet et comporte plusieurs pages, il vaut mieux laisser le navigateur gérer la navigation

  • Points souvent cités comme inconvénients des SPA

    • Les utilisateurs de technologies d’assistance ne perçoivent pas les changements de contexte lors des changements de page
    • La gestion du focus lors des changements de page n’est pas assurée
    • Il est impossible d’utiliser les boutons précédent et suivant du navigateur
    • En cas de coupure réseau, il est impossible de récupérer après une erreur
    • Mais ces problèmes peuvent aussi être résolus dans une SPA

  • J’aimerais que tout l’Internet suive ce conseil

  • Il faut donner la priorité aux solutions simples

  • Je me demande pourquoi Linux ne figure pas dans la liste

  • Beaucoup de gens semblent apprécier cette approche

    • Je me demande pourquoi la tendance générale consiste à utiliser inutilement JavaScript et des frameworks comme React

  • Utiliser du HTML et des données préchargées côté serveur, puis traiter côté client ce qui peut l’être

    • Utiliser un minimum de CSS et du JavaScript vanilla
    • Cela peut sembler dépassé aux collègues, mais on ne passe à côté de rien

  • Beaucoup de SPA posent problème, mais toutes les SPA ne sont pas problématiques

    • Des exemples comme VitePress et SolidJS montrent que cela peut très bien fonctionner
    • Il n’y a presque personne qui n’utilise pas JavaScript
    • Même sur des appareils peu puissants, traiter le JavaScript ne pose pas de problème
    • Les problèmes d’accessibilité n’ont rien à voir avec l’usage ou non d’une SPA
    • Svelte intègre même des avertissements liés à l’accessibilité

  • Le server-side rendering n’est pas non plus systématiquement une bonne chose

    • Il faut être prudent lorsqu’on utilise des frameworks JavaScript côté client
    • La base de code peut grossir, et les nombreuses tâches à traiter côté client peuvent entraîner des problèmes de performances
    • La dépendance à du code tiers peut compliquer la maintenance
    • Lorsqu’on utilise un framework JavaScript, il faut pouvoir démontrer quel bénéfice concret il apporte à l’utilisateur
    • Il faut être conscient des impacts négatifs et pouvoir les atténuer
    • Il faut n’utiliser un framework que là où HTML et CSS seuls ne suffisent pas
    • Chaque partie de l’interface utilisateur doit être conçue comme un composant distinct
    • Même si le JavaScript ne se charge pas, le reste de la page se charge normalement