- htmx a été sélectionné pour la première promotion du GitHub Open Source Accelerator, ce qui lui donne l’occasion de collaborer avec des projets open source matures et d’en tirer des enseignements
- Cette participation permettra de faire connaître plus largement hypermedia et l’approche de htmx auprès de la communauté des développeurs
- htmx prévoit de profiter de la période de l’Accelerator pour lancer les travaux sur htmx 2.0
- Un autre enjeu important reste d’apprendre à faire du travail sur htmx un emploi à plein temps afin d’assurer la maintenance et le développement du projet
- Les projets sélectionnés aux côtés de htmx couvrent divers domaines de l’open source, comme la sécurité, la documentation, l’authentification, les notifications ou les CMS, ce qui montre l’étendue du GitHub Accelerator
Les opportunités pour htmx
- htmx a été sélectionné pour la première promotion du GitHub Open Source Accelerator
- Cette sélection lui permettra d’apprendre auprès de développeurs et projets open source à succès et de collaborer avec eux
- htmx estime que ce programme lui permettra de faire connaître plus largement hypermedia et htmx
- La participation à l’Accelerator poursuit deux objectifs principaux
- Lancer les travaux sur htmx 2.0
- Apprendre à faire du travail sur htmx un emploi à plein temps
Les autres projets open source sélectionnés
- BoxyHQ : suite d’API pour la sécurité et la confidentialité, qui aide les équipes d’ingénierie à créer et déployer plus rapidement des applications cloud conformes aux réglementations
- Cal.com : outil de planification qui permet d’organiser des réunions sans échanges d’e-mails à répétition
- Crowd.dev : centralise les données de communauté, de produit et de clients afin d’identifier quelles entreprises participent à des projets open source
- Documenso : alternative open source à DocuSign, qui vise à inspirer confiance grâce à l’auto-hébergement et à la possibilité d’examiner son fonctionnement interne
- Erxes : alternative open source à HubSpot, permettant de créer des expériences adaptées à différents types d’activité via un XOS unique
- Formbricks : permet d’envoyer des enquêtes à des groupes d’utilisateurs segmentés à n’importe quelle étape du parcours utilisateur, et de recueillir jusqu’à 6 fois plus d’insights grâce à des micro-sondages ciblés
- Forward Email : service gratuit de redirection d’e-mails pour domaines personnalisés, utilisé depuis plus de 6 ans par des créateurs, des développeurs et des entreprises
- GitWonk : outil open source de documentation technique conçu et développé avec un fort accent sur l’expérience développeur
- Hanko : outil open source d’authentification et de gestion des utilisateurs pour l’ère des passkeys, intégrable en quelques minutes dans des applications web et mobiles
- Infisical : plateforme open source de chiffrement de bout en bout pour gérer en toute sécurité les secrets et configurations à l’échelle des équipes, des appareils et de l’infrastructure
- Novu : infrastructure de notifications open source pour développeurs, fournissant des composants et des API pour gérer tous les canaux de communication en un seul endroit
- OpenBB : démocratise la recherche en investissement via un écosystème financier open source, avec OpenBB Terminal pour effectuer des recherches en investissement depuis n’importe où
- Sniffnet : outil de surveillance réseau qui facilite le suivi du trafic Internet
- Typebot : fournit des blocs pour créer des expériences de chat originales, intégrables n’importe où dans une application afin de collecter des résultats
- Webiny : CMS serverless open source de niveau entreprise, mettant l’accent sur la propriété des données, l’extensibilité et la personnalisation
- Webstudio : sélectionné comme alternative open source à Webflow
1 commentaires
Avis sur Hacker News
Bonjour, comme beaucoup d’entre vous le savent, je suis le créateur de htmx et je peux répondre aux questions à ce sujet
htmx a gagné fortement en popularité grâce à la vidéo de fireship dev (https://www.youtube.com/watch?v=r-GSGH2RxJs) et à une série de vidéos du célèbre streamer Twitch ThePrimeagen
Les lecteurs de HN pourraient aussi trouver intéressants mes articles sur htmx et l’hypermédia en général, rassemblés ici : https://htmx.org/essays, ainsi que le livre récent que j’ai publié avec quelques auteurs sur l’hypermédia, htmx et Hyperview, un hypermédia mobile : https://hypermedia.systems
Évidemment, je suis fan de htmx, mais le cœur du sujet, plus profondément, c’est selon moi l’hypermédia. C’est un concept qui mérite d’être exploré, même si vous ne prévoyez pas d’utiliser htmx dans votre développement quotidien
Il existe aussi beaucoup d’excellentes bibliothèques orientées hypermédia, comme Hotwire de 37signals ou https://unpoly.com, ma préférée après htmx
C’est d’une grande aide pour beaucoup de développeurs Django
Il y a quelques mois, quand j’ai implémenté une fonctionnalité de likes pour des articles, avant htmx il fallait appeler un serveur d’API JSON avec jQuery et mettre à jour le nombre de likes ; avec HTMX, j’ai eu l’impression d’écrire simplement du HTML ordinaire avec ma logique Django
C’est l’une des meilleures choses que j’aie découvertes jusqu’ici, et le traitement des formulaires est aussi très simple. HTMX améliore fortement à la fois l’expérience utilisateur et l’expérience développeur
Quand on sait que, même dans des projets très populaires, la majeure partie du code est généralement prise en charge par les contributeurs existants, c’est un signal de croissance fort
https://devboard.gitsense.com/bigskysoftware/htmx
À noter : c’est un outil que j’ai créé
En parcourant un peu le site et les exemples, il semble que l’approche mette l’accent sur les réponses HTTP serveur contenant un balisage complet, utilisé ensuite pour mettre à jour l’état côté client — autrement dit, plutôt sur la réécriture du DOM
Je me demande si htmx offre aussi des compromis pour les déclencheurs purement côté client ou le contenu généré côté client
L’avantage des frameworks client centrés sur JavaScript aujourd’hui, c’est qu’ils permettent de transférer autant de travail que possible vers le navigateur afin de réduire l’usage des données et du CPU côté serveur. À l’échelle du Web, cela fait une grande différence
Je me demande si HTMX peut aussi répondre à cet objectif d’ingénierie, ou s’il s’agit d’un projet poursuivant un but complètement différent. Je comprends qu’un client comme Facebook ne soit pas orienté hypermédia, mais la comparaison sera malgré tout difficile à éviter
Il paraît naturel, auto-documenté, et bien conçu. Il donne vraiment l’impression d’être une extension naturelle de HTML
Pour moi, la seule pièce qui manque à htmx est un modèle de composants ; pour ceux qui cherchent cela, il semble très bien s’accorder avec Astro[1]. Astro permet de définir et d’utiliser des composants HTML sans le coût d’exécution de Vue ou React
[1] http://astro.build
Htmx me fait penser à Tailwind. Dans les deux cas, on crée des noms d’attributs et des valeurs qu’une bibliothèque lit à l’exécution
Le fait de ne pas avoir besoin de build front-end est un très gros avantage pour la plupart des développeurs qui n’ont ni envie ni besoin de toucher à npm et webpack
La limite en taille de page semble être celle d’une petite application monopage ; si elle devient trop grosse, il suffira probablement de la découper en une autre application monopage
Ce qui manquera surtout aux développeurs React/Vue, c’est sans doute la vision où l’on dispose d’un objet unique représentant l’état global, rendu en UI par une fonction unique définie hiérarchiquement dans la base de code des composants
Mais cette vision elle-même est lourde, suscite beaucoup de divergences d’opinion et de fatigue émotionnelle, et entraîne avec elle le build front-end et toutes ses variantes déroutantes
Je ne l’utilise pas encore, mais je suis déjà un grand fan
C’est une bonne nouvelle
Au cours de l’année écoulée, j’ai utilisé htmx avec de très bons résultats et une expérience vraiment gratifiante, et c’était particulièrement excellent pour faire du rendu côté serveur en Clojure avec hiccup
Une fois qu’on a compris htmx, il est presque surprenant de voir à quel point c’est simple et flexible. Il est difficile de croire que HTML n’ait pas évolué ainsi en tant qu’hypermédia
Il devient très clair que le développement web aurait dû évoluer de cette façon. J’espère qu’un jour, ce que htmx fait en JavaScript sera directement intégré à HTML et aux clients navigateur
Si vous considérez à tort htmx comme une sorte de dérivé d’Angular, ou si vous ne comprenez pas l’intérêt de faire progresser l’architecture hypermédia, je vous recommande vivement de lire les excellents articles du site. Vous comprendrez alors ce qu’est REST et pourquoi le vrai HATEOAS est important : https://htmx.org/essays/
Il existe aussi un livre gratuit : https://hypermedia.systems/
Il y a 10 à 15 ans, au lieu d’étendre et d’enrichir l’hypermédia, cette idée nouvelle et puissante du web des débuts, nous avons pris une mauvaise direction coûteuse en essayant de recréer des clients lourds par-dessus le web avec des architectures d’API JSON
Je suis content que htmx existe et qu’il convienne à beaucoup de gens, mais dans mon travail, ce n’a souvent pas été la meilleure option. Et ce n’est pas grave
C’est formidable que le web ait pu se développer de multiples façons, et il n’est pas nécessaire de considérer qu’il aurait absolument dû évoluer dans une seule direction
La plus grande erreur du développement web de ces dix dernières années environ a été de penser qu’il devait y avoir une seule bonne réponse
Que l’on construise le prochain Gmail ou un blog statique, le cargo cult de l’industrie affirme qu’il faut tout faire de la même manière, mais le bon sens dit le contraire
Cela suffirait pour plus de 98 % du web. Pour les 1,9 % restants, on peut utiliser une petite bibliothèque JavaScript
Les 0,1 % restants seulement sont des webapps en pur JavaScript
Cela ressemble à la même idée : parsemer HTML de quelques attributs pour rendre dynamiques les cas simples
Angular 1, Vue et beaucoup d’autres frameworks ont commencé ainsi, puis, après avoir gagné une certaine popularité, se sont développés en frameworks complets d’application monopage en raison de la demande réelle pour des cas plus difficiles
Si je devais choisir un framework « façon Angular 1 », je choisirais quelque chose qui documente clairement ses limites et offre une voie claire vers un framework d’application monopage mature lorsqu’il faut dépasser ces limites. Si quelqu’un connaît un tel framework, merci de le partager
Je suis fan de HTMX « depuis avant que ce soit cool »
Je suis très heureux de l’intérêt et du succès récents, et j’apprécie aussi pas mal les moqueries et réactions, souvent sur le ton de la blague, venues du côté frontend, qui semble croire que le Web a été inventé en 2013 et qu’ils ont bâti la ville
J’avais déjà un biais à l’époque de Backbone.js : même si je comprenais une partie de la douleur à l’époque, je restais assez sceptique
Puis React est arrivé, et quand des gens jeunes et pleins d’énergie ont commencé à transformer des sites web très simples de 5 pages en machines de Rube Goldberg à base de frameworks frontend, j’ai encaissé mes jetons technologiques et je n’ai plus touché à ces choses-là
Les détails d’implémentation sont assez différents, mais l’idée d’applications fondées sur l’hypermédia était au cœur de tout ce que nous faisions
Malheureusement, à long terme, nous n’avons pas réussi à convaincre les gens, et le développement piloté par les blogs — autrement dit le culte du cargo — a remplacé nos efforts
Voir HTMX gagner en popularité maintenant me donne donc, dans une certaine mesure, l’impression d’être récompensé. C’est agréable de voir que nous n’étions pas les seuls à penser avec ces concepts
Bien sûr, si le concept était solide, cela veut peut-être dire que mon exécution laissait à désirer, donc je ne devrais peut-être pas trop m’en réjouir
J’ai aussi entendu dire qu’un groupe avait vendu ses guitares et acheté des platines
J’ai entendu dire qu’on avait réécrit un endpoint HTTP pour qu’il renvoie du JSON, et que c’était ça, REST
J’ai aussi entendu dire que le groupe avait vendu ses platines et racheté des guitares
J’ai entendu dire qu’on avait réécrit un endpoint HTTP pour qu’il renvoie des fragments HTML templatisés, et que c’était ça, HATEOAS
Je perds le fil, je le retrouve, je le perds, puis je le retrouve
Cela dit, Backbone était un peu lâche, et n’a pas vraiment eu un côté très entreprise avant l’arrivée d’Angular
Quoi qu’il en soit, si ce courant d’applications web est devenu populaire autour de moi, c’est parce qu’il séparait backend et frontend, et qu’un seul backend, généralement REST/JSON, pouvait alimenter séparément les clients mobiles et web
C’est pour cela que nous faisions des applications monopages, mais cela semble aujourd’hui oublié
Dans mon univers, pour des applications derrière un login, cela avait du sens. Mais « eux » voulaient aussi faire des sites publics sur Internet, comme des boutiques en ligne, sous forme d’applications monopages
Je peux aussi le comprendre. J’ai créé quelques sites avec Gatsby, et la navigation est incroyablement rapide tout en restant indexable par les moteurs de recherche
Mais dans certains cas, les choses sont devenues de plus en plus complexes, jusqu’à inclure du React côté serveur. Heureusement, je n’ai pas eu à y toucher
D’un autre côté, j’aimerais que htmx, et plus généralement l’hypermédia, soient acceptés comme des outils. Ils sont utiles, mais au bout du compte ce ne sont que des outils
J’aimerais aussi qu’ils soient reçus ainsi par les gens du frontend qui n’avaient pas vraiment réfléchi à l’hypermédia depuis un moment
Je ne vois pas les deux approches comme mutuellement exclusives, et je suis d’accord avec le concept d’applications web transitionnelles de Rich Harris, c’est-à-dire une façon de mélanger les deux approches
Simplement, je place la limite à partir de laquelle on abandonne l’hypermédia pour passer à une approche côté client plus sophistiquée à un endroit différent du sien
Moi, en tout cas, c’est clairement ce que je pense
J’ai commencé avec Perl en 1996, puis j’ai traversé presque tous les courants : PHP, jQuery, Drupal, Backbone, Node, Angular, ClojureScript, React, GraphQL, jusqu’à NextJS.
Htmx donne l’impression d’être une branche qui s’écarte de ce courant, et mérite qu’on s’y attarde.
Htmx pose une bonne question : « La complexité de votre travail est-elle fondamentalement côté serveur ou côté client ? »
Pour la plupart des sites web, la complexité est fondamentalement côté serveur. Nous ne sommes pas, pour la plupart, en train de créer Figma ou Google Sheets. Beaucoup de sites web, même avec beaucoup d’interactions, ne sont que des applications CRUD avec une interface agréable.
Des frameworks comme NextJS tentent de corriger le problème de clients excessivement complexes en déplaçant React vers le serveur, mais ils augmentent souvent la complexité au lieu de la réduire.
Dans ce cas, ne faudrait-il pas retirer React de la stack ? Pour un client complexe, on peut passer outre le DOM et JavaScript et utiliser canvas avec du WebAssembly compilé. Pour un serveur complexe, on peut utiliser des mises à jour fines du DOM pilotées par le serveur.
Le problème que je vois dans cette approche, c’est que même si, pour la plupart des sites web, la complexité se trouve côté serveur, il existe presque toujours quelques tâches très complexes qui doivent être côté client : édition d’images, tri/filtrage/calcul en temps réel, gestes de glisser-déposer et tactiles, etc.
Il faut une approche hybride. La simple compatibilité ne suffit pas. On peut utiliser htmx et React sur la même page web, mais il faut les isoler l’un de l’autre. Ce que je veux, ce n’est pas l’isolation, mais une intégration fondamentale.
Le framework idéal devrait prendre en charge des mises à jour réactives et fines du DOM, tout en s’intégrant étroitement avec du WebAssembly compilé chargé des tâches complexes côté client.
Je veux écrire tout mon code dans un langage puissant, pas en JavaScript. Le débogueur doit gérer à la fois le serveur et le client, et la différence entre les deux doit disparaître. Ce doit être du vrai développement full-stack, autrement dit une application à stack unique.
Clojure + ClojureScript semble s’approcher d’une application à stack unique, mais seulement en surface.
Si un framework incontournable voyait le jour pour Common Lisp, une application à stack unique lui conviendrait parfaitement.
L’approche hybride est l’approche par îlots défendue par Astro : https://docs.astro.build/en/concepts/islands/
Cette approche fonctionne bien avec htmx et ses compagnons, et dans nos projets htmx nous l’utilisons avec un peu de JavaScript vanilla simple pour les parties qui ont besoin d’interactivité.
Pour les petits et moyens projets, et les petites équipes, cela peut suffire. C’est vraiment rafraîchissant de pouvoir ouvrir les outils de développement, pointer une partie de la page, puis comprendre toute cette partie simplement en regardant le HTML et un petit morceau de JS.
Que ce soit côté serveur ou côté client, on code de la même manière en C#. Au premier chargement de la page, tout est rendu côté serveur, puis WebAssembly prend progressivement le relais et commence à charger le code C# côté client afin d’accélérer les interactions d’UI qui n’ont pas besoin de données serveur.
Cela fonctionne bien, mais le défi actuel est de réduire la taille des fichiers WebAssembly. Pour l’instant, ils font plusieurs Mo.
https://visualstudiomagazine.com/articles/2023/04/20/blazor-...
Félicitations. C’était amusant de créer un petit projet avec Htmx, mais comme j’ai fini par utiliser beaucoup openlayers, j’ai choisi autre chose.
Les bibliothèques de cartographie sont réputées lourdes en JavaScript côté client, et Svelte était un meilleur outil pour cette tâche.
Je compte le réutiliser dans de futurs projets Golang et suivre son évolution.
Si votre application a besoin d’un front-end simple ou de complexité moyenne, et surtout si vous utilisez déjà des fragments de templates[0], je vous recommande vivement d’essayer HTMX. Même en venant du monde JavaScript, c’est assez agréable à utiliser.
Et la personne qui tient le compte Twitter[1] est vraiment drôle.
[0] https://htmx.org/essays/template-fragments/
[1] https://twitter.com/htmx_org
Il m’est difficile de prendre htmx au sérieux comme outil pour construire des apps ou des sites web modernes. J’ai l’impression qu’il rend impossibles des fonctionnalités auxquelles les utilisateurs s’attendent désormais
Par exemple, une recherche à facettes qui filtre les dates avant/entre/après, tout en n’affichant les filtres que lorsque l’utilisateur le souhaite, ou encore la possibilité de changer l’écran de résultats vers une autre colonne, une carte, ou une vue dessinée sur un canvas comme un graphique
On peut sans doute en faire une partie avec htmx, mais à un moment donné il faudra bien du JSON
Angular permet aussi de faire ce genre de choses, et avec quelque chose comme SolidJS, c’est même assez agréable à construire
Une API JSON peut être réutilisée par d’autres apps, alors que htmx me donne l’impression que quelqu’un a réinventé Thymeleaf
J’étais du même avis, et la vidéo explique concrètement comment ils ont implémenté la recherche à facettes avec htmx
Pour la deuxième partie, il faudra probablement écrire directement du JavaScript ou passer par hyperscript
Il faudrait le construire réellement et l’utiliser intensivement pour savoir si c’est une bonne approche, mais je vois clairement aussi des scénarios où cela colle bien
La remarque sur l’API JSON est pertinente. Si vous avez besoin d’une API publique, cela doit entrer dans la décision. Mais tous les projets n’ont pas cette contrainte
Même un smartphone n’a aucun problème à rechercher dans un tableau de mille lignes
Dans ce genre de cas, avec htmx, je fournirais à l’utilisateur un large ensemble de données, puis j’autoriserais un filtrage temps réel plus fin avec JS
Si vous voulez aussi pouvoir rechercher dans des données qui ne sont pas affichées au départ, vous pouvez les envoyer avec une classe CSS masquée, puis retirer cette classe lorsqu’elles correspondent à la recherche
Comme toute autre technologie, htmx convient très bien à certains ensembles de problèmes. Tant qu’on n’essaie pas de lui faire faire de force des numéros pour lesquels il n’est pas doué, tout va bien
Ce genre de chose est suffisamment complexe pour nécessiter un certain niveau de scripting complet, et je ne suis pas contre en soi
https://htmx.org/essays/hypermedia-friendly-scripting/
Grâce aux méandres de ma carrière, j’ai quasiment évité les guerres de frameworks JavaScript frontend, donc je suis content de voir le bon vieil HTML ordinaire revenir renforcé
C’est un recul du point de vue de la dégradation progressive
Je pense qu’il faudrait des exemples impressionnants réalisés avec htmx. Ce serait bien d’avoir des exemples « made with htmx » qui ouvrent la voie à un nouveau type d’expérience web
Les gens ont catalogué htmx comme étant destiné à des cas d’usage simples, pas au point de sortir les « armes sérieuses »
Il y a une part de vérité, mais c’est réducteur. L’approche retour au serveur associée à htmx constitue une catégorie distincte, qui n’a pas été explorée plus tôt pour diverses raisons
HTMX ressuscite une ancienne catégorie d’apps d’une façon indépendante du backend
Il ne fait rien de nouveau, ni rien qui justifierait une « nouvelle catégorie d’apps »
C’est une manière de construire de l’hypermédia, c’est-à-dire des sites centrés sur le contenu, comme des catalogues marchands, des forums, des frontends d’administration ou des blogs
C’est similaire à jquery/liveview/turbolinks, mais indépendant du backend, et avec peu, voire pas du tout, de logique JS frontend à maintenir
Dès que vous avez besoin d’interactions lourdes comme Google Docs ou Figma, les avantages apportés par htmx diminuent fortement
https://htmx.org/essays/a-real-world-react-to-htmx-port/
C’est un frontend e-commerce écrit avec HTMX et Hyperscript
https://www.makaron.cz/
On pourrait créer un frontend TodoMVC en HTMX, mais quel backend utiliser ? Go, C#, Rust et quelques autres choix semblent naturels, mais comme toujours, cela dépend du contexte
Si je mentionne C#, c’est parce que ASP.Net MVC + Razor semble s’accorder très proprement avec le paradigme HTMX
Je n’ai aucun lien avec eux, mais c’est construit avec htmx et un peu de JS pour les fonctionnalités plus complexes
Sachant que htmx a explicitement pour objectif d’étendre une bonne vieille approche, je ne sais pas vraiment s’il peut offrir un « nouveau type d’expérience web »
Au début, htmx paraît séduisant, mais dès qu’on veut créer quelque chose pour lequel on utiliserait normalement JavaScript, vanilla ou avec un framework, comme un bouton de menu déroulant, on finit par envisager hyperscript
Puis, en regardant les exemples, on n’aime pas trop voir des sortes de phrases dans le code, et on passe à autre chose
Il faudrait peut-être essayer htmx sans hyperscript, ou bien donner plus de temps à hyperscript
Mais si l’on prévoit de maintenir cela pendant plusieurs années, c’est trop déroutant, et je n’ai pas envie de me retrouver lié à cet outil si je finis par ne plus jamais l’utiliser
htmx se moque complètement de l’outil d’interaction côté client que vous utilisez, donc c’est une question distincte de l’utilité de htmx
Personnellement, si je voulais éviter les outils de build JS et autres, je choisirais htmx + Alpine.js
Comment pourrait-on le gérer quand il prend de l’ampleur et devient complexe ?
J’ai déjà aidé sur une application qui utilisait htmx, et il y avait deux problèmes. Je me demande si d’autres ont eu une expérience similaire, si ces problèmes venaient d’une mauvaise utilisation de la technologie, ou si des travaux sont en cours pour les résoudre
Premièrement, il fallait beaucoup de middleware personnalisé dans les contrôleurs pour décider si un endpoint devait renvoyer le HTML de la page entière ou seulement le fragment nécessaire à htmx
Côté htmx, cela semble simple, mais c’est probablement une partie que tous les projets utilisant htmx doivent recréer
Deuxièmement, il fallait tenir une sorte de registre autour de
hx-trigger. Quand l’UI devient complexe, beaucoup d’éléments doivent réagir à des changements externesAu lieu de lire un état et de s’attendre à ce que le framework planifie la mise à jour, il fallait gérer soi-même la liste des événements auxquels réagir
Quelqu’un a-t-il eu la même impression ?