- htmx est né de
intercooler.js, un outil basé sur jQuery qui proposait des fonctionnalités dynamiques uniquement via des attributs HTML
- Les raisons souvent citées de la longue adoption de jQuery sur de nombreux sites web sont sa prise en main simple, une API cohérente et la possibilité de l'utiliser de manière partielle et souple
htmx, le nouveau jQuery
- htmx vise aussi à devenir une bibliothèque stable utilisable pendant longtemps, comme jQuery
- Il a fixé comme objectif de créer des services web maintenables pendant 100 ans, conçus pour rester utiles et durables sans changements majeurs
- La stabilité comme fonctionnalité
- La politique de mise à jour principale de htmx consiste à préserver la stabilité de l’API et de l’implémentation
- Lors d’une montée en version, il adopte une approche centrée sur les « utilisateurs existants » afin de garantir que le fonctionnement reste inchangé
- Pas de nouvelles fonctionnalités comme feature
- htmx vise à ne pas ajouter sans discernement de nouvelles fonctionnalités à son cœur
- Si nécessaire, il s’appuie sur les nouvelles API prises en charge par les navigateurs ou sur des extensions, en conservant un cœur simple
- Sorties trimestrielles
- Il prévoit de publier de nouvelles releases tous les trimestres (environ tous les 3 mois)
- Il n’impose pas de mises à niveau ; si la version 1.x fonctionne correctement, vous pouvez la garder en l’état
Promouvoir l'hypermedia
- htmx n’a pas pour objectif d’être une solution globale pour l’ensemble d’une application web, mais de généraliser le contrôle hypermedia
- Pour cela, il faut améliorer la façon de s’intégrer avec les moteurs de templates, les backends, les bases de données, etc. situés en dehors de htmx
- Même sans ajouter de nouvelles fonctionnalités à htmx, la croissance de l’écosystème des outils environnants autour de l’hypermedia augmente in fine l’utilité d’htmx
- Soutien aux outils complémentaires
- htmx fournit certaines fonctionnalités via les attributs HTML uniquement, mais le choix du backend ou de la DB reste entièrement laissé à l’utilisateur
- Conçu pour être compatible avec des backends variés, il soutient des patterns de développement centrés sur l’hypermedia
- Il met en avant le concept de « template fragment », qui facilite le remplacement partiel de pages, contribuant au développement de l’écosystème des moteurs de templates
- Il existe désormais de nombreux exemples de moteurs de templates offrant une fonction de fragments
- Il reste encore de nombreuses pistes pour améliorer l’expérience d’écriture d’applications web basées sur l’hypermedia
- htmx se concentre sur la stimulation du progrès des outils et technologies environnants, plutôt que sur les fonctionnalités du cœur, pour faire progresser l’écosystème global
- Rédaction, recherche et standardisation
- htmx prévoit de diffuser et de faire évoluer les idées liées à l’hypermedia dans son ensemble, plutôt que d’étendre ses propres fonctionnalités
- Grâce à des initiatives comme le projet Triptych notamment, il s’efforce d’intégrer des idées htmx dans la norme HTML
- À terme, il espère que la plateforme web prendra en charge nativement des fonctionnalités similaires à htmx au niveau standard
- Même le code htmx écrit aujourd’hui restera progressivement compatible, mais un jour on peut espérer un monde où des patterns UI similaires pourront être implémentés sans bibliothèque
Intercooler avait raison
- Depuis l’époque de
intercooler.js, il a été maintenu en évitant les changements importants, selon une approche de « stewardship » qui consiste à ne pas casser
- htmx reprend cette philosophie et vise à survivre longtemps en tant qu’outil robuste et fiable
1 commentaires
Avis de Hacker News
Après avoir partagé son expérience de portage terminée de HTMX vers Hotwire, il estime que l’idée de HTMX est bonne mais que son exécution est insuffisante. Il indique qu’il y a beaucoup de bugs, que la compatibilité avec les fonctionnalités du web et du navigateur n’est pas bonne, et que la documentation manque. Après le portage vers Turbo et Stimulus, il a obtenu une base de code plus stable et plus facile à comprendre.
Il est d’accord avec la tendance à privilégier la stabilité et souligne qu’un projet construit sur des abstractions instables a de fortes chances de générer des bugs à l’avenir. Il note que cela n’a pas d’impact sur les petits projets, mais qu’une solution dont l’utilité est prouvée peut évoluer en projet majeur.
Il partage son expérience de développement d’applications avec Django et HTMX, indiquant qu’il préfère React ou Vue, mais que HTMX peut convenir aux développeurs back-end. Il juge aussi que HTMX est aussi difficile à tester que les frameworks front-end modernes.
Il exprime des inquiétudes sur l’accessibilité de HTMX et dit vouloir être certain de sa compatibilité avec les lecteurs d’écran. Il accorde plus de poids à l’expérience utilisateur réelle qu’au bon usage des attributs ARIA.
Il remercie HTMX pour avoir réduit la charge de travail des développeurs en gérant élégamment certaines tâches JavaScript via une abstraction élégante. Il estime que c’est une bonne leçon sur la gestion de la complexité.
Il dit qu’il cherche à déployer HTMX dans une grande entreprise de développement logiciel et qu’il l’utilise comme expérience de pensée en mentorat. Cela l’amène à se demander si une SPA est vraiment nécessaire.
Il approuve l’idée que « pas de nouvelles fonctionnalités, c’est une fonctionnalité » et considère positif qu’il ne soit pas nécessaire de mettre à jour un logiciel trop souvent.
Il espère que les fonctionnalités HTMX seront intégrées dans la norme HTML, ce qu’il dit faire via le projet Triptych. Il souhaite qu’elles soient incluses nativement dans le navigateur.