HTML First

• En utilisant d’abord les fonctionnalités natives fournies par le navigateur, on peut réduire la dépendance à des langages et toolchains supplémentaires lors de la création d’une application web
• React a renforcé la fiabilité du développement UI avec des modèles comme props, state et les composants, mais a déplacé le centre de gravité du développement de HTML vers JavaScript
• Entre-temps, le W3C, le WHATWG, l’IETF et le TC39 ont apporté des milliers d’améliorations aux langages fondamentaux du Web, et leur intégration dans les principaux navigateurs a affaibli une partie des raisons qui rendaient React nécessaire
• HTML First est moins un mouvement cherchant à convaincre les développeurs satisfaits de React qu’une manière de fournir un langage commun à ceux qui s’intéressent à une approche centrée sur HTML, afin de structurer leur réflexion et d’en discuter avec leurs collègues
• Cela relève davantage d’une préoccupation pratique : réexaminer si les langages fondamentaux du Web et les fonctionnalités du navigateur suffisent, à eux seuls, à créer des logiciels rapides et accessibles

---

La manière de développer prônée par HTML First

• HTML First privilégie HTML, CSS, JavaScript et les fonctionnalités natives du navigateur lors de la création de logiciels web
• L’idée centrale est de réduire les couches d’abstraction ajoutées au-dessus de la plateforme web
  • Les langages et toolchains supplémentaires font aussi partie de ces couches à réduire
• L’objectif est une manière de développer qui place au centre les capacités déjà fournies par le navigateur, et n’ajoute des outils par-dessus qu’en cas de besoin

Le développement web, plus complexe depuis React

• Avant React, il était courant d’écrire l’interface en HTML, puis de compléter avec des outils comme jQuery ce que HTML ne prenait pas en charge nativement
  • Les exemples les plus représentatifs sont l’envoi de requêtes asynchrones et la mise à jour du DOM
• Des bibliothèques comme React ont résolu plusieurs problèmes du développement web traditionnel
  • Les modèles props et state, qui transmettent explicitement les données d’un élément parent à un élément enfant, ont réduit certains types de bugs
  • En regroupant UI, styles et comportements dans des composants, elles ont permis d’installer facilement dans sa propre base de code ce que d’autres avaient créé
• Pour bénéficier de ces avantages, il a fallu passer d’une façon de travailler principalement en HTML à une façon de travailler principalement en JavaScript
  • JavaScript est considéré comme un langage plus complexe
  • Il fallait aussi apprendre de nombreux concepts et outils introduits par React
• Malgré cette hausse de complexité, l’industrie a accepté ce compromis, et ces bibliothèques sont devenues la manière standard de créer des applications web
  • Avant React, les nouveaux développeurs apprenaient d’abord HTML et CSS, puis JavaScript
  • Après React, la tendance s’est inversée : on apprend d’abord JavaScript et React, puis le reste

Les points de réévaluation créés par les améliorations de la plateforme web

• Le W3C, le WHATWG, l’IETF et le TC39 ont ajouté des milliers d’améliorations aux langages natifs du Web pendant que l’approche React se généralisait
  • Ces améliorations ont été intégrées à Chrome, Safari, Firefox et Edge
  • Un grand nombre d’entre elles traitent directement une partie des raisons pour lesquelles les gens utilisaient React
• À mesure que le coût du développement logiciel augmente et que les améliorations des navigateurs sont largement déployées, de plus en plus de personnes se demandent si les couches supplémentaires restent encore nécessaires aujourd’hui
• L’idée de HTML First reste encore minoritaire dans l’industrie
• Cette approche vise surtout à aider ceux qui s’intéressent déjà à un développement centré sur HTML à consolider leurs idées et à disposer d’un langage et de concepts pour communiquer avec leurs collègues
• Le message central est qu’il est possible, pratique et raisonnable de créer des logiciels web beaux, rapides, simples à utiliser et accessibles en s’appuyant principalement sur les langages et fonctionnalités natives du Web

[GN⁺]

Avis sur Hacker News

• J’aime l’idée, mais franchement, les exemples sont faibles
  L’exemple de la partie « définir autant que possible le style et le comportement via des attributs HTML inline » ne semble pas vraiment fonctionner, et si l’on veut ajouter davantage de styles, on se retrouve avec un paramètre chaîne passé à ClassList.add qui ne fait que grossir
  Personnellement, je trouve button:active { background: green; } bien plus lisible, mais l’auteur semble considérer cela comme complexe à cause de l’approche de « localité du comportement » (Locality of Behaviour)
  Je suis d’accord avec l’idée de « si vous avez besoin d’une bibliothèque, utilisez-en une qui exploite les attributs HTML plutôt qu’une bibliothèque centrée sur JavaScript ou une syntaxe personnalisée », mais l’exemple recommandé, « on input put me into #output », paraît plus maladroit que la bibliothèque citée comme mauvais exemple, et du JavaScript sans framework semble largement suffire
  Comme exemple de « préférer le HTML “brut” à une couche cachée compilée en HTML », il conseille de ne pas utiliser les helpers de balises ERB de Rails, mais ces helpers gèrent pas mal de choses qui deviendraient vite brouillonnes si on les écrivait directement dans des templates minimaux. L’exemple laisse de côté des aspects réalistes comme les ID DOM uniques, les balises Turbo et l’itération

  • La partie « définir autant que possible le style et le comportement via des attributs HTML inline » m’a aussi fait tiquer
    Le style et le comportement devraient être séparés, et à une échelle significative, le seul modèle qui ait du sens est de les relier uniquement par des références
    Techniquement, on peut mettre toutes les connexions SQL et toutes les requêtes SQL codées en dur d’une application Python dans un seul long fichier, mais c’est une mauvaise pratique ; ce principe me semble du même ordre

• Cette partie est déroutante : « si vous avez besoin d’une bibliothèque, utilisez-en une qui exploite les attributs HTML plutôt qu’une bibliothèque centrée sur JavaScript ou une syntaxe personnalisée »
  Pourtant, l’exemple recommandé est _hyperscript [0]. C’est une bibliothèque centrée sur une syntaxe personnalisée, qui consiste simplement à mettre, dans un attribut HTML, des scripts écrits dans un langage supplémentaire à apprendre. Je ne sais pas si c’est sérieux
  [0] https://hyperscript.org

  • On dirait que c’est écrit comme une liste de conseils pour promouvoir hyperscript
    Les exemples sont aussi assez faibles. La solution native, c’est-à-dire le tout premier conseil, fonctionne tout aussi bien à elle seule
  • D’accord. L’exemple qui met une phrase de DSL obscure comme valeur d’un attribut nommé _ paraît vraiment étrange et confus
    Je préférerais encore mettre une instruction JavaScript pure dans un onclick explicite ou un autre attribut d’événement, pour voir immédiatement ce qui se passe
  • Si l’on suit les conseils de l’auteur, Alpine.js aurait sans doute été une meilleure recommandation, puisqu’il utilise des attributs HTML et du JavaScript intuitif
  • hyperscript est lié à HTMX, donc certains semblent vouloir le mettre en avant, mais à mon avis c’est plutôt un jouet amusant
  • Il est aussi possible que l’auteur ait inversé les exemples recommandés et non recommandés

• Je comprends l’intention. Utiliser les fonctionnalités intégrées de HTML, c’est propre et simple
  Mais ce n’était déjà pas pratique il y a dix ans, et ça ne l’est toujours pas. Je ne trouve pas non plus que des choses comme htmx soient particulièrement meilleures que des solutions plus lourdes comme React
  Chaque fois que je vois cette approche, je pose toujours les mêmes questions. À quoi ressemblent les menus déroulants, les sélections multiples, les sélecteurs de date ? Les navigateurs proposent-ils désormais des sélecteurs de date ? Oui. Leur apparence et leur comportement sont-ils cohérents d’un navigateur à l’autre ? Non. Peut-on les harmoniser par le style ? Non plus
  La sélection multiple, c’est pareil. Exiger Shift/Ctrl-clic pour sélectionner plusieurs éléments est totalement inacceptable du point de vue de l’expérience utilisateur. L’élément natif fonctionne encore comme ça et on ne peut pas le changer. Et il n’y a pas que la sélection multiple : même les éléments de sélection simples ont une apparence médiocre et sont généralement difficiles à personnaliser
  Ce n’est pas un hasard si chaque nouveau framework finit par avoir ces composants tiers. Les éléments intégrés ne suffisent pas. C’est la même raison pour laquelle, même si la page Array de MDN s’enrichit chaque année de nouvelles fonctionnalités natives, 90 % de mes projets dépendent encore de lodash. C’est mieux qu’il y a dix ans, oui, mais ce n’est pas encore suffisant

  • Si je pense rapidement au seul cas du sélecteur de date, un site web est conçu pour ses utilisateurs
    Les utilisateurs peuvent utiliser des navigateurs différents, mais un même utilisateur utilise probablement le même navigateur sur tous les sites qu’il visite
    Donc, à mon avis, il est plus important qu’un sélecteur de date soit cohérent sur tous les sites dans un même navigateur plutôt que cohérent sur tous les navigateurs au sein d’un même site. Bien sûr, si l’on a besoin de fonctionnalités personnalisées, c’est une autre histoire
  • Quand tu dis « exiger Shift/Ctrl-clic pour sélectionner plusieurs éléments est totalement inacceptable du point de vue UX », tu veux dire qu’il ne faut pas faire la sélection multiple de cette manière ? Si oui, je serais curieux de savoir comment il faudrait faire
    Quand je veux sélectionner 10 ou 15 éléments consécutifs dans une liste, je ne connais pas vraiment de meilleure UI que Shift+clic pour l’instant
  • « Leur apparence et leur comportement sont-ils cohérents d’un navigateur à l’autre ? Non » : c’est étrange quand on se souvient qu’autrefois, le look and feel natif était considéré comme une condition indispensable pour les applications desktop
    Je préférerais largement que les composants UI de tous les sites web suivent le look and feel natif du navigateur, hors design propre au site, plutôt que de réinventer chacun leur propre style idiot. Bien sûr, il faudrait que les navigateurs se soucient de rendre ça agréable visuellement
  • À en juger par le reste de la discussion, l’élément input est tristement célèbre parce que ses modes d’interaction varient beaucoup selon les navigateurs, alors que la plupart des autres éléments HTML ont un comportement représentatif bien défini

• Je suis d’accord avec la plupart des arguments, mais cet article me semble un peu contradictoire. Il recommande Tailwind tout en disant d’« éviter l’étape de build »
  Déployer d’énormes ressources CSS/JS va aussi à l’encontre du principe d’inclusivité. Beaucoup de gens n’ont pas une connexion rapide ni un ordinateur suffisamment puissant

  • Je n’utilise plus Tailwind aujourd’hui, mais d’après mon expérience, Tailwind ne m’a pas fait déployer d’énormes ressources CSS/JS
    En fait, je ne vois pas du tout quel JavaScript côté client Tailwind produirait. Ma dernière expérience remonte à la 2.x, donc je ne sais pas trop si ça a changé
    Pour la taille du CSS, mon expérience était même inverse : la sortie de Tailwind était généralement bien plus petite que du CSS écrit à la main
    Bien sûr, je ne suis pas contre le CSS pur, mais il est au moins tout aussi facile d’en faire n’importe quoi
  • J’ai créé une bibliothèque de CSS atomique qui ne nécessite pas d’étape de build. Si ça intéresse quelqu’un, elle est ici. Spoiler, évidemment : ça n’intéresse personne : https://casscss.github.io/cass/
  • Deno Fresh évite l’étape de build en utilisant Twind : https://twind.dev/
    Cela dit, de mémoire, il ne fournit pas toutes les fonctionnalités de Tailwind complet. Globalement, ce qui m’a frustré avec Fresh, c’est qu’il est en pratique largement construit sur Preact et Twind, sans vraiment l’assumer clairement : il faut d’abord adhérer à ces bibliothèques
  • Tailwind dispose d’une CLI autonome utilisable comme étape de build
    Je suis assez d’accord que c’est un peu étrange de la recommander dans le contexte de cet article, mais l’étape de build peut être rendue extrêmement minimale, et le résultat reste du CSS inspectable, ce qui est appréciable
    J’utilise Tailwind sur mon site personnel, et tout le reste est en HTML pur. Lancer la CLI en mode watch quand j’écris les styles ne me dérange pas vraiment
  • Comme options sans build, deux solutions sont bonnes : auto-héberger le CDN de Tailwind v3, ou utiliser https://github.com/gnat/css-scope-inline
    Les deux sont étonnamment rapides et parsèment même plus de 10 000 éléments

• C’est intéressant en théorie ou dans des exemples simples, mais j’aimerais voir un gros projet qui applique ça, et concrètement quelle différence cela a faite
  Les objectifs présentés au début de l’article sont excellents, mais les conseils eux-mêmes m’ont un peu déçu. Je ne vois pas bien comment cela fonctionnerait au-delà de situations très basiques, et encore moins comment cela permettrait d’atteindre ces objectifs
  Je suis pour exploiter au maximum la plateforme web, et totalement pour réduire la complexité autant que possible. Mais je suis très sceptique sur le fait que ces principes y parviennent ; ils pourraient même augmenter la complexité en créant plusieurs façons de faire la même chose
  Pour le dire avec bienveillance, cette liste ne permet pas de savoir si ces principes ont été réellement éprouvés, ou si l’on suppose simplement qu’ils fonctionneront comme espéré

  • Je ne vois pas pourquoi une bonne pratique devrait forcément être bonne pour les gros projets
    Je pose sincèrement la question. Les gens avancent souvent cet argument, et je ne l’ai jamais compris
    De mon point de vue, 95 % du Web correspond à des projets petits à moyens. La plupart des technologies devraient se concentrer là-dessus. On utilise des solutions simples pour des projets simples, et on ajoute de la complexité plus tard si nécessaire
  • Au travail, j’ai essayé de pousser un frontend de style HTML d’abord, mais une fois des développeurs frontend ordinaires recrutés, ils ne comprenaient fondamentalement pas l’approche : ils voulaient tout faire avec des div et que VueJS contrôle toute la logique et tout le contenu
    Une chose à moitié objective que nous avons perdue, c’est l’accessibilité. Comme des liens ont été naïvement réimplémentés avec des div auxquelles on a attaché des écouteurs de clic, la majeure partie du site n’est pas navigable au clavier
    C’est assez préoccupant. Quand la réglementation nous rattrapera, nous nous précipiterons pour récupérer ce que nous avons abandonné
    Cela dit, je suis assez d’accord qu’il est difficile de trouver des exemples connus de sites « HTML d’abord ». J’y crois, mais je n’ai pas vu de cas réellement bien déployé. La raison pourrait toutefois être purement liée à la formation : quand HTML est devenu puissant, la formation des développeurs frontend était déjà profondément ancrée autour des frameworks
  • Pour un développeur frontend plus jeune que jQuery, commencer un projet en suivant ces conseils serait une bonne occasion d’apprendre pourquoi nous utilisons des choses comme des étapes de build, et à quel point le développement avant le HMR était pénible
    L’auteur ne semble pas avoir réellement essayé cela sur un projet impliquant plus de deux personnes et prenant en charge 99 % des navigateurs existants. Il ne semble pas non plus avoir exécuté son propre code. C’est peut-être parce que mon écran n’est pas savoureux, mais onlick n’est pas un gestionnaire sur une div
  • Nous avons oublié de vieilles leçons. Le backend d’abord était un mécanisme de défense contre les gens qui ne croient que ce qu’ils voient et ne font pas confiance aux experts
    Si vous construisez un produit qui a l’air de fonctionner mais qui, en réalité, ne fonctionne pas, ils ne le comprennent pas. On se retrouve alors poussé à trop promettre et à livrer moins que prévu
    L’un des avantages moins connus des tests unitaires est qu’ils permettent d’obtenir davantage d’assurance qualité avant que du code invisible pour la direction ne soit relié. Ils réduisent cette période inconfortable entre l’apparition du premier écran et la sortie
  • D’accord
    En 1999, j’ai créé mon premier site web en HTML pur, CSS et JS pur, et je l’ai hébergé sur Geocities
    Depuis, j’ai créé des sites et des applications avec PHP/WordPress/Yii/Laravel, Ruby/Rails/Sinatra/Jekyll, React/Typescript et ClojureScript
    Aujourd’hui, React, les composants TSX, le CSS-in-TS, les Effects et le Context me donnent l’impression d’être enfin à la maison. J’ai enfin le sentiment d’avoir un vrai langage de programmation complet pour le web/le frontend. Un langage explicitement conçu pour le frontend, sur des principes modernes comme la programmation fonctionnelle et réactive
    Ce n’est que maintenant que je peux faire du développement logiciel. Avant ça, HTML, CSS, JS pur et PHP relevaient plutôt du bricolage. Rails était bien pour le full-stack, mais ne brillait pas côté frontend
    Quand la stack web sera prête aussi pour les applications, je me passerai des frameworks. Pour l’instant, j’admets qu’elle suffit peut-être pour des sites

• Cette année, j’ai abandonné. Il est devenu impossible de continuer à se battre contre les monstres React, Vue et Angular, avec leurs bundlers, transpileurs et toute la camelote qui les accompagne
  Node et npm vous balancent « 7 vulnérabilités graves et 8 vulnérabilités critiques » même sur un projet créé il y a quelques secondes. Il faut télécharger des milliers de fichiers, parmi lesquels il peut même y avoir des choses comme un wrapper de valeur booléenne
  L’époque où un serveur backend Python servait aussi le frontend semble révolue pour moi

  • Enragez ! Enragez contre la machine !
    En réalité, ni vous ni personne d’autre n’avez vraiment besoin de cette lourde boursouflure de frontend JavaScript. Il suffit de dire non
    Servez des pages légères depuis le backend ou le cache, et si nécessaire, laissez CSS faire les choses élégantes
    Vous profiterez de temps de rendu rapides et d’une accessibilité mondiale
  • Appuyez sur le bouton d’éjection. Une bonne partie de ce que le Web a de bon se trouve dans Phoenix Liveview. On peut créer des sites web réactifs et séduisants sans ces délires React/Node insensés
    Cela dit, honnêtement, les exemples de cet article sont bizarres. Je ne vois pas pourquoi il faudrait écrire des balises brutes à la main plutôt que d’utiliser les helpers de formulaires Phoenix, qui génèrent automatiquement les erreurs et plusieurs commodités. Je comprends l’esprit
  • C’est possible. Il suffit d’essayer htmx

• L’argument central semble être que l’utilisateur devrait pouvoir cliquer sur View Source et comprendre ce qui se passe. Pour un site web, je suis d’accord
  Pour une webapp, au moins dès qu’elle dépasse 50 lignes, il y a de fortes chances que vous ayez envie d’utiliser un langage typé. Techniquement, on peut utiliser du .js avec des annotations de type dans des commentaires spéciaux et le compilateur TypeScript, mais je n’ai pas trouvé ça très agréable
  J’ai été assez fortement attiré par cette idée par le passé, et je trouve triste que la plupart des sites d’aujourd’hui ne soient plus qu’un bloc d’une ligne de HTML illisible. Il y a de la beauté et de l’élégance à tout distribuer dans un seul fichier HTML, sans dépendances. Une seule requête réseau suffit
  Au final, j’ai bien créé un « système de build » pour faciliter l’édition, mais mon système de build, c’est cat. On obtient ainsi un logiciel autonome et portable contenu dans un fichier lisible par un humain
  Dans le même esprit, ce qu’il y a de plus génial dans le développement web, c’est qu’on peut créer son premier programme interactif avec seulement Notepad et le navigateur par défaut. Il suffit de glisser-déposer un fichier HTML dans le navigateur. C’est magique
  Ajout : j’ai découvert un avantage inattendu du HTML autonome. Le logiciel devient immunisé contre le bit rot. J’ai ouvert un ancien projet dans Web Archive et les fichiers JS externes n’avaient pas été archivés. Tristesse. En revanche, celui-ci se charge correctement, car tout le JS est dans le HTML. Victoire
  https://web.archive.org/web/20210508133239id_/https://andai....
  C’est un hommage à l’ancien SodaPlay Constructor. Je n’ai pas réussi à faire l’éditeur. Libre à vous de voir le source

  • Je suis sceptique sur ce point. Aujourd’hui, il existe beaucoup de façons de regarder « derrière le rideau » dans les outils développeur
    Vue du DOM, onglet réseau, vue du tas, fonction intégrée de mise en forme du JavaScript
    Bien sûr, « View Source » reste important, mais je me demande si son importance est encore aussi absolue que le disent les gens de HTMX
  • « Il y a de la beauté et de l’élégance à tout distribuer dans un seul fichier HTML, sans dépendances. Une seule requête réseau suffit »
    Avec les URL data:, c’est désormais encore plus simple. C’est aussi utile pour éviter les problèmes des URL file://, qui ne nécessitent même pas de serveur HTTP
  • Ajout : il existe une proposition visant à étendre JavaScript avec des annotations de type, ce qui pourrait permettre d’exécuter directement dans le navigateur un « sous-ensemble assez important » de TypeScript. Bonne chose !
    https://github.com/tc39/proposal-type-annotations
  • Je ne pense pas que l’auteur défende un système à fichier unique. Il veut plutôt dire, sans vouloir vous le dire

• La « localité du comportement » est une règle définie de façon beaucoup trop vague. Ce n’est qu’un nouveau nom pour quelque chose qui va à l’encontre de la séparation des préoccupations.
  Qualifier CSS d’action fantomatique à distance est aussi très exagéré. Il y a de bons principes, mais l’argumentation est assez faible, et on aurait pu le dire beaucoup plus simplement.

  • Vu depuis une organisation C# qui a trop d’interfaces, j’y vois une réaction naturelle à des systèmes excessivement abstraits.
    Si « transformer un bouton rouge et rebondissant en bouton bleu et tremblant » oblige à suivre un labyrinthe de 3 à 7 interfaces et classes pour trouver quelle classe a besoin d’une nouvelle implémentation et ce qui peut être réutilisé, ce qui ressemblait à un changement de 10 minutes devient une demi-journée passée à maudire intérieurement le compilateur ou les anciens développeurs.
    Bien sûr, il faut abstraire, mais il faut aussi disposer d’une façon de regrouper le comportement au même endroit pour ne pas avoir à toucher 6 fichiers afin de modifier un composant.
    https://htmx.org/essays/locality-of-behaviour/#conflict-with...
  • Tailwind implique aussi une étape de build et comporte tout autant d’« action fantomatique à distance ». Sinon, on utiliserait simplement du CSS inline.
    Avec Tailwind, on fait confiance à une bibliothèque tierce pour abstraire la spécification CSS à notre place, et on suppose que cette quasi-spécification abstraite sera respectée selon la configuration de build.
  • Si la « localité du comportement » est une règle définie de façon vague, la séparation des préoccupations ne l’est-elle pas aussi ?
    Que faut-il séparer ? Selon quelles lignes découper ? Comment décide-t-on de ces lignes ? Quand est-il pertinent d’extraire une préoccupation vers une autre classe, un framework, du markup, etc. ? Quand vaut-il mieux la garder au même endroit ?
    La réponse est : « ça dépend ».
    Si l’on ne sépare rien, on obtient du spaghetti ; si l’on sépare au maximum, partout et tout le temps, on obtient un code surabstrait aussi difficile à maintenir que du spaghetti.
  • L’objectif principal affiché est « d’élargir considérablement le vivier de personnes capables de travailler sur des bases de code de logiciels web ». C’est assez différent de conseils destinés aux programmeurs en général.
    Si les valeurs par défaut fonctionnent bien, la personnalisation n’est pas indispensable. C’est pourquoi les gains d’efficacité apportés par CSS, entre autres, passent après la simplicité.
  • Le problème est multidimensionnel.
    Si l’on voit HTML comme un langage de document/de présentation, on ne peut pas nier le styling. CSS ajoute non seulement du styling, mais aussi des animations.
    Quoi qu’il en soit, CSS peut aussi être vu comme de la programmation orientée aspect.
    Le vrai problème décrit ici est le manque de bons outils transversaux aux langages et aux frameworks.

• S’appuyer sur des frameworks plus simples quand c’est possible a du sens. Mais l’idée de supprimer l’étape de build est quasiment une plaisanterie.
  Il suffit de rendre l’étape de build plus efficace et, si nécessaire, de ne pas l’inclure en production.
  Je ne vois pas non plus pourquoi il faudrait privilégier l’ajout d’attributs à HTML. S’agit-il de créer des documents et de les héberger comme site web ? Dans quel autre monde serait-ce préférable ? CSS n’est pas difficile à parcourir, et il faudrait plutôt encourager de meilleures pratiques CSS.
  Les scripts frontend peuvent brouiller le styling, mais si l’on n’en a pas besoin, il suffit de ne pas s’appuyer sur cette approche. Mettre cela dans une feuille de styles est plus facile que d’ajouter des attributs avec JavaScript ; c’est donc déjà évident.
  Certains conseils du type « n’utilisez que ce dont vous avez besoin » ont du sens et sont évidents. Mais le reste est confus ou franchement absurde. Je ne vois pas non plus pourquoi il faudrait considérer comme une bonne chose de pouvoir copier une page HTML entière. Honnêtement, je m’en fiche, et même si l’on ne pouvait pas voir le HTML de certaines pages, il existe déjà littéralement des millions de ressources pour apprendre HTML.
  Dans l’ensemble, ça laisse perplexe.

  • Une bonne partie de tout cela est une réaction au culte de la complexité dans le secteur du développement web.

• Tout cet article est un antipattern et un mauvais conseil. On dirait qu’il a été écrit par quelqu’un qui n’a jamais connu les douleurs de croissance liées à la création de sites web complexes.
  Au début, nous aussi, nous construisions des sites web comme ça, puis tout a commencé à casser à cause des effets de bord, des noms de classes en conflit et d’une mauvaise observabilité interne, et React est venu à la rescousse.
  Le pattern recherché, c’est l’amélioration progressive, et la sortie doit être du HTML propre et minifié, que JavaScript vient enrichir. Autrement dit, il faut une étape de build. C’est exactement l’inverse des conseils de cet article.

  • Créer des sites web avec React comporte aussi des pièges, et utiliser React signifie introduire beaucoup de complexité.
    Si vous n’utilisez pas déjà NodeJS côté backend, il vaut mieux éviter ReactJS sauf quand vous en avez réellement besoin.