Pourquoi htmx est une mauvaise idée

Depuis un certain temps, j’ai suivi htmx. Au début, je pensais que c’était un mème assez drôle/gênant et qu’il servait de légère bouffée d’air frais par rapport au vrai travail effectué dans le développement web, des choses comme React et Vue.js qui poussent réellement l’état de l’art.

Malheureusement, à un moment donné, des gens ont commencé à prendre htmx au sérieux pour des raisons inconnues. C’est un virage extrêmement alarmant qui me préoccupe profondément pour l’avenir du développement web.

Et je ne suis pas le seul à être alarmé : vous pouvez lire un excellent article à ce sujet :

“Ils montrent ouvertement leur ignorance, puis attribuent toutes sortes de mérites infondés à ce qu’ils ont fait en espérant que tout le monde les félicite pour cela.”

Tellement vrai. Tellement, tellement vrai.

Malheureusement, le langage de cet excellent article est académique et, sans une solide compréhension de l’HTML théorique, bon nombre des points les plus importants passeront au-dessus de la tête d’un développeur web typique.

Ainsi, dans cet article, je vais tenter de présenter, en langage clair pour le développeur web profane, pourquoi htmx est une mauvaise idée.

Le Code Est Mauvais

Tout d’abord, considérez le code d’htmx. Ils utilisent des éléments obsolètes partout, presque aucune fonctionnalité JavaScript moderne (bonjour, avez-vous entendu parler de ES6 ?), ils polluent l’espace de noms, et ainsi de suite.

Le pire de tout, c’est juste un gros tas de JavaScript ! Un seul fichier ! Il n’est pas du tout décomposé. Si cette personne était étudiante dans l’un de mes cours, je l’échouerais uniquement sur cette incompréhension totale de la programmation, quelque chose que tout étudiant en informatique de première année devrait pouvoir comprendre.

Un bon logiciel commence par un code propre, et ce code est sale.

Pas d’Outils de Construction

Le prochain signal d’alarme est l’absence d’une étape de construction traditionnelle. Non seulement htmx n’a pas d’étape de construction traditionnelle, les privant ainsi des avantages que le reste de la communauté JavaScript apprécie, mais ils mentent à ce sujet !

Et ça empire.

Si vous regardez de près, même s’ils prétendent ne pas avoir d’étape de construction, ils ont en fait une étape de construction, ce ne sont que des scripts bash ad hoc qu’ils ont écrits eux-mêmes.

Ridicule et malhonnête. Honteux.

Pas de TypeScript

Malgré l’utilité de TypeScript pour un projet comme htmx, les auteurs ont résisté obstinément à son utilisation. Une partie de cela est leur opposition irrationnelle à une étape de construction (qu’ils ont en fait, au fait !) mais une autre partie est un engagement ridicule à “expédier du code source débogable”. Bien sûr, comme tout développeur JavaScript qui n’est pas un idiot complet le sait, TypeScript prend en charge des fonctionnalités de débogage qui le rendent parfaitement débogable. Malgré ce fait, les auteurs continuent d’insister pour utiliser une version obsolète de JavaScript pour le développement.

Dans une admission tacite qu’ils ont fait une erreur, ils ajoutent tardivement des annotations TypeScript à leur base de code (j’utilise le mot “lâchement” ici). Tout cela pour compenser le fait qu’ils n’ont pas fait la chose évidente et correcte initialement et simplement écrire tout le projet en TypeScript moderne et modulaire.

La seule bonne nouvelle ici est qu’au moins ils ont un , et étant donné l’état de la base de code, ils feraient mieux de l’avoir !

Technologie Antiquée

D’accord, cela couvre les principaux (mais loin d’être tous !) problèmes avec la base de code d’htmx elle-même. Passons à des problèmes plus généraux avec htmx.

Le premier problème flagrant est quelque chose dont les auteurs se vantent encore : il utilise . En réalité, c’est juste une façon prétentieuse de dire “il utilise HTML”, je ne sais pas pourquoi ils insistent pour utiliser un terme différent et confus, mais bon.

Eh bien, si vous ne l’avez pas remarqué, HTML a plus de trente ans maintenant. C’est ancien. De plus, nous avons beaucoup d’expérience avec l’approche que ces gars recommandent. Ce n’est pas comme si htmx faisait quelque chose de nouveau : React, Angular et Vue.js (bien meilleurs qu’htmx, d’ailleurs) existent depuis littéralement une éternité.

Même avant cela, nous avions jQuery.

Regardez ce code jQuery de 2008 :

Et maintenant regardez les trucs super innovants que les gens d’htmx nous donnent :

Incroyable. Étonnant.

Ce serait drôle si ce n’était pas si exaspérant.

Pas de Composants

La prochaine raison de ne pas utiliser htmx est qu’il n’y a pas de composants disponibles pour cela. Si vous optez pour React, vous obtenez des choses comme , et .

Avec htmx, vous n’obtenez… rien. Vous devez décider quels composants vous voulez utiliser, puis comment les intégrer avec htmx en utilisant des événements, etc.

Voulez-vous vraiment passer du temps à comprendre comment fonctionnent des choses comme et ensuite également comment les intégrer avec htmx ? Cela n’a aucun sens. Il est bien plus judicieux d’opter pour une bibliothèque frontale avec des composants intégrés prêts à l’emploi que vous pouvez simplement utiliser sans tracas.

Pas de Séparation Front-End/Back-End

Une autre raison majeure d’éviter htmx est qu’il élimine la séparation entre les équipes Front-End et Back-End. Ils ont même une page avec une équipe lorsque leur entreprise (stupidement) est passée de React à htmx.

La séparation Front-End/Back-End a été extrêmement réussie pour de nombreuses entreprises, permettant aux ingénieurs Front-End de se concentrer sur la création d’une bonne expérience utilisateur, et aux ingénieurs Back-End de se concentrer sur la mise en place de la couche d’accès aux données.

Oui, il y a parfois des difficultés de coordination entre les deux équipes, avec les ingénieurs Back-End se plaignant que les ingénieurs Front-End changent trop fréquemment leurs exigences et les ingénieurs Front-End se plaignant que les ingénieurs Back-End avancent trop lentement. Mais nous avons des technologies comme GraphQL et REST pour aider avec cela, c’est un problème résolu à ce stade dans l’existant.

La séparation Front-End/Back-End s’est avérée être un très bon modèle organisationnel pour les entreprises, en particulier lorsqu’elles développent leur équipe de développement, et l’abandonner au profit du développement “Full Stack” (soi-disant) est risqué et, franchement, stupide.

Les Ingénieurs Back-End Font des Interfaces Utilisateurs Médiocres

Mis à part si la séparation Front-End/Back-End est bonne ou non, nous pouvons affirmer de manière définitive que les ingénieurs Back-End font des interfaces utilisateur médiocres.

Regardez simplement . Vous avez des styles en ligne, des tableaux, une multitude de balises d’image sans descriptions pendant longtemps. Juste un mélange de mauvais HTML, de la part de personnes qui essaient de nous dire d’utiliser HTML !

Vous devriez laisser vos interfaces utilisateur entre les mains de personnes qui comprennent comment les construire correctement, et ces personnes sont, aujourd’hui, principalement des développeurs SPA Front-End.

Vulnérabilités XSS

Revenons à une raison plus technique pour ne pas utiliser htmx, cela vous expose à une classe de problèmes de sécurité appelés , abrégés “XSS”.

Le problème ici est fondamental pour la conception d’htmx : il vous permet et même vous encourage à mettre du <em>comportement</em> dans votre balisage. Encore une fois, nous voyons une violation claire de . Nous savons depuis longtemps dans le développement web que vous devriez séparer votre balisage, votre style et votre comportement dans des fichiers HTML, CSS et JavaScript respectivement.

En violant cette vérité évidente et bien connue, htmx vous rend vulnérable à ce que d’autres injectent du comportement dans votre application web si vous ne correctement.

Parfois, l’auteur d’htmx fera un commentaire malin du genre “Eh bien, que pensez-vous de l’attribut ?”, mais c’est différent, évidemment.

Pas d’Emplois

Une autre raison pratique de ne pas utiliser htmx est qu’il n’y a, pour arrondir, aucun emploi htmx.

Je viens de faire une recherche d’emplois htmx sur Indeed et j’ai trouvé un total de deux : un chez Microsoft et un au Oak Ridge National Labratory.

Une recherche pour “React”, en revanche, donne 13 758 emplois.

Sérieusement, développeur, avec quelle technologie voulez-vous lier votre carrière ?

Personne à Embaucher

Le revers du problème ci-dessus est que, si vous êtes une entreprise, il n’y a, pour arrondir, aucun développeur htmx.

Tout le monde va dans des bootcamps et apprend React. Si vous voulez avoir un grand bassin potentiel d’employés (peut-être que votre entreprise a un fort taux de rotation pour une raison quelconque, peut-être que vous voulez maintenir les salaires des employés bas, peut-être qu’une petite équipe d’ingénieurs full stack entraverait votre construction de royaume), il est beaucoup plus logique d’opter pour le Grand Chien du développement front-end.

Aujourd’hui, ce chien est React.

Dupliquer (Ou Plus !) Vos APIs

Revenons au côté plus technique des choses, si vous adoptez htmx et que vous voulez <em>aussi</em> avoir une application mobile ou une API pour que des tiers l’utilisent, vous devrez créer cette API entièrement séparément des points de terminaison de votre application web.

Ici encore, nous constatons que les , ignorant complètement la duplication du travail impliqué ici.

Il est bien plus logique d’avoir une seule API entretenue par une seule équipe Back-End qui peut servir de manière flexible à tous vos besoins.

C’est évident et, franchement, cela ne vaut même pas la peine d’en discuter.

Cela ne Sera Pas Évolutif

Un autre problème technique avec htmx est qu’il ne sera tout simplement pas évolutif. Cela peut fonctionner pour de petites applications, mais à mesure que les applications deviennent plus grandes, le modèle htmx s’effondre et devient un désordre. Le modèle de composants de React et d’autres outils frontaux garde tout compartimenté et testable. Cela rend beaucoup plus facile de garder les grands codebases propres.

À titre d’exemple, considérez , qui a commencé en utilisant une technologie très similaire à htmx. Il a récemment commencé à adopter React et est maintenant beaucoup plus stable qu’auparavant. Ils auraient été mieux s’ils avaient simplement commencé avec React et construit le tout de manière moderne et basée sur des composants, mais au moins ils font le bon choix maintenant. Mieux vaut tard que jamais.

Le Créateur Est Dérangé

Enfin, et peut-être la raison la plus importante de ne pas utiliser htmx : le créateur est clairement dérangé.

Il suffit de regarder le : non professionnel, enfantin, intentionnellement provocateur.

Ou considérez le fait qu’il publie ) sur son propre site.

L’onglet essais , dont la plupart sont gênants et qui n’ont pas leur place sur un site web d’une bibliothèque frontale qui s’attend à être prise au sérieux.

Apparemment, il permet et fait une de ces annonces d’emploi super gênantes sur LinkedIn.

Une bouffonnerie effrénée.

Lorsque vous choisissez une bibliothèque frontale, vous choisissez, dans une certaine mesure, l’auteur de cette bibliothèque comme collègue. Voulez-vous vraiment travailler avec ce type ? Moi, certainement pas.

Conclusion

J’espère que cela vous a convaincu que choisir htmx & hypermédia pour votre application web est une qui ne peut provenir que de . Ne prêtez pas attention aux fanboys et fangirls avec leurs absurdités “C’est tellement fini”, “Nous sommes tellement en arrière”, profils de PDG et mèmes enfantins.

Les logiciels, et en particulier les logiciels Front-End, sont une affaire sérieuse et doivent être traités avec la même gravité que des choses comme le droit et la politique, deux autres activités extrêmement sérieuses et productives. Nous devrions soutenir les bibliothèques qui se concentrent sur l’innovation et la sophistication, pas sur des bibliothèques cassées et rétrogrades dont le créateur passe la plupart de son temps à publier des choses ridicules sur Twitter.

C’est juste du bon sens : htmx sucks.

Source de l’article