Hotwire : la technologie HTML over the wire

 (hotwired.dev)
2 points par GN⁺ 2024-06-03 | 1 commentaires | Partager sur WhatsApp
  • Hotwire est une approche qui consiste à transmettre du HTML plutôt que du JSON pour créer des applications web modernes, avec l’objectif d’obtenir un premier chargement rapide et une bonne réactivité sans beaucoup de JavaScript
  • Comme le rendu reste dans les templates serveur, le flux de développement peut rester simple quel que soit le langage utilisé
  • Les frameworks créés par 37signals pour HEY se combinent entre eux pour former l’écosystème Hotwire, du web jusqu’à plusieurs plateformes
  • Turbo, composant central, gère les transitions de page, l’envoi de formulaires, le découpage en composants et les mises à jour partielles via WebSocket sans écrire de JavaScript
  • Les interactions personnalisées que Turbo ne couvre pas sont complétées par Stimulus, tandis que Hotwire Native permet de créer des applications mobiles natives à partir d’une application web existante

Une approche qui rend le HTML côté serveur puis l’envoie

  • Hotwire est une approche alternative pour construire des applications web modernes en mode HTML-over-the-wire
  • Au lieu du JSON, elle transmet du HTML sur le réseau, ce qui permet de créer des applications avec peu de JavaScript
  • L’objectif est d’obtenir un premier chargement rapide, de conserver le rendu des templates côté serveur et d’offrir une expérience de développement plus simple et plus productive
  • L’idée est de ne pas renoncer à la vitesse et à la réactivité attendues d’une application monopage traditionnelle
  • HTML-over-the-wire peut servir de référence pour créer ses propres outils, ou bien on peut utiliser tels quels les frameworks Hotwire conçus par 37signals pour HEY

Le rôle de Turbo, Stimulus et Hotwire Native

  • Turbo est le composant central de Hotwire
    • Il fournit des techniques complémentaires pour accélérer les transitions de page et l’envoi de formulaires
    • Il permet de diviser des pages complexes en composants et de diffuser des mises à jour partielles via WebSocket
    • Ces fonctionnalités sont fournies sans avoir à écrire de JavaScript
  • Stimulus est utilisé quand un code personnalisé est nécessaire et que Turbo seul ne suffit pas
    • Turbo couvre généralement au moins 80 % des interactions qui nécessitaient traditionnellement du JavaScript
    • Stimulus permet de gérer l’état et les connexions dans une approche centrée sur le HTML
  • Hotwire Native est un framework web-first destiné à la création d’applications mobiles natives
    • Il fournit les outils nécessaires pour créer une application mobile en réutilisant une application web existante

À lire aussi

1 commentaires

 
GN⁺ 2024-06-03
Avis sur Hacker News

  • Il existe une version moins marketée de cette fonctionnalité : htmx : https://htmx.org/
    Un seul fichier JavaScript permet d’obtenir ce genre de fonctionnalités, et même si je l’ai surtout vu utilisé avec des backends Go, ça a l’air assez flexible. J’envisage de l’essayer depuis environ un an

    • Au moins selon les standards de Hacker News, htmx est bien plus visible
      Rien que sur l’année écoulée, il y a eu des centaines de soumissions sur HN 0, avec même un post à plus de 1000 points. En face, Hotwire a eu moins de 30 soumissions sur l’année 1, et le plus populaire d’entre eux, c’est cet article
    • Je ne comprends pas l’idée que htmx serait moins marketé. Je n’avais jamais entendu parler de Hotwire, mais htmx, j’en vois absolument partout
      Il suffit de passer rapidement sur YouTube pour voir des influenceurs dev mettre htmx en avant en permanence, avec leur visage en miniature
    • On peut aussi mentionner https://unpoly.com, qui inclut d’autres fonctionnalités
    • HTMX est probablement mieux marketé que n’importe quel framework
      Twitter est très actif autour du projet, il revient souvent sur la chaîne YouTube de The Primeagen, et il est assez populaire
    • Moins marketé ? J’ai l’impression que htmx déborde sur toutes les plateformes sociales

  • Si vous cherchez quelque chose de similaire côté PHP/Laravel, je recommande vivement Livewire : https://laravel-livewire.com/
    Pour des projets plus complexes, j’utilise toujours React, mais pouvoir tout écrire en Blade/PHP tout en gardant des éléments d’UI réactifs reste toujours rafraîchissant. Je me souviens aussi avoir vu un package qui permet de rendre des composants React/Vue à l’intérieur de Livewire quand c’est nécessaire : https://minglejs.unitedbycode.com/. Ça semble être une porte de sortie intéressante quand il faut réutiliser des packages existants

  • J’étais plutôt négatif sur Hotwire/Livewire au départ, mais je considère maintenant que ce sont des outils adaptés selon le contexte
    Envoyer des templates partiels over the wire, c’est une approche hypermédia ; c’est juste qu’on ne construit plus beaucoup de bonnes applications hypermédia aujourd’hui. J’en suis arrivé là en relisant htmx et l’article REST de RTF ; je ne pense pas que l’hypermédia soit une architecture intrinsèquement supérieure, mais c’est une option légitime parmi d’autres, et c’est bien de la voir continuer à évoluer, même lentement

  • C’est probablement la façon la plus simple de créer une PWA sans tomber dans le terrier de lapin de React/Vue/Svelte
    Je les ai aussi utilisés et je les trouve excellents, mais comparés à htmx, ils me semblent davantage centrés sur l’expérience développeur que sur la technique elle-même. La concurrence entre les deux dépendra sans doute surtout de leur intégration avec tel ou tel framework backend

    • C’est peut-être vrai si l’app mobile n’est qu’une WebView. Sinon, il faut maintenir à la fois une REST API pour l’application mobile et un gestionnaire de requêtes Hotwire/Livewire qui sert des fragments HTML
      Personnellement, je pense qu’une PWA est un problème côté client et qu’il ne faut pas ajouter de dépendances serveur pour ça, mais le gérer côté client
    • Je me demande pourquoi cette approche serait moins un terrier de lapin que les alternatives mentionnées

  • Voici une discussion HN de 2020, plus proche de la sortie initiale : https://news.ycombinator.com/item?id=25507942

  • J’ai l’impression qu’on a presque bouclé la boucle. Je me souviens qu’en 2005 ou 2006, on interceptait les clics, on ajoutait des paramètres, puis on recevait seulement des fragments partiels de HTML déjà rendus pour remplacer le contenu via .innerHTML

    • Avant l’arrivée d’AJAX au début des années 2000, Adam Rifkin avait montré une démo de sa startup KnowNow, et voir une page web se mettre à jour toute seule sans rechargement était assez sidérant
      L’astuce consistait à laisser une requête HTTP ouverte en permanence pour que le serveur envoie parfois des mises à jour, et ces mises à jour étaient elles aussi du HTML. À l’époque, il n’était peut-être même pas possible de manipuler le DOM, donc c’était peut-être littéralement une page avec des balises jamais fermées
    • Plutôt qu’un retour à la case départ, il serait plus juste de dire que différents paradigmes d’interface web élargissent leur champ d’action
      Les frameworks de rendu serveur facilitent davantage les interactions côté client, et React facilite aussi le rendu serveur via RSC. Pour une application web très interactive, le SPA garde tout de même l’avantage
    • On entend ce discours chaque fois que Hotwire ou une bibliothèque similaire monte en puissance, mais en pratique le CRUD simple basé sur AJAX n’a jamais disparu
      Il y a énormément de projets SPA, mais cela ne décrit pas tous les sites web du monde
    • https://animasci.com/ utilise une approche similaire
      La pagination y était implémentée ainsi : on fait défiler la page, on clique sur « Show more », le client demande au serveur la page suivante sous forme de fragment HTML, la charge dans un iframe invisible, puis l’ajoute à la page courante une fois le chargement terminé
    • J’aimais beaucoup Wicket à la fin des années 2000 et je détestais JavaScript, mais gérer l’état de l’UI et les templates côté serveur pouvait facilement devenir un piège en matière de performances et de montée en charge dans un contexte d’équipe
      Vu à quel point le web, JavaScript et TypeScript se sont améliorés depuis, j’ai du mal à me réenthousiasmer pour cette approche

  • Je n’ai pas souvent travaillé sur des applications web exigeant un frontend hautement interactif, mais dans des boutiques e-commerce et des applications Rails internes, Turbo et Stimulus ont fortement réduit la quantité de choses qu’un nouveau développeur doit apprendre

    • Garder une stack simple n’a jamais été si difficile que ça à la base
      Par exemple, sur un projet Django, j’ai rapidement construit tout un outil interne avec KnockoutJS, qui avait fait ses preuves, et cela rejoint en partie l’esprit de HTMX. Arrow.JS, encore jeune, est aussi dans cette veine. La complexité, surtout côté UI, était le plus souvent auto-infligée, les anciennes approches n’ont jamais été dépassées et reviennent même en force. Il existe toute une génération de jeunes développeurs qui a débuté pendant la période la plus absurde où l’industrie essayait de convaincre tout le monde que toutes les applications web devaient devenir des monstres surcomplexes et pénibles à supporter
    • Pour avoir utilisé Stimulus, Stimulus était nul et je ne l’utiliserai plus jamais. Hotwire, en revanche, était correct

  • J’utilise Hey en payant depuis son lancement, et si l’expérience web de Hey est la meilleure vitrine de Hotwire, je préfère passer mon tour
    Sur une connexion lente, c’est mauvais. C’est peut-être parce que les développeurs n’ont pas prévu d’états de chargement ou d’erreur, peut-être à cause de la complexité, peut-être à cause de bugs dans Hey. Je n’en sais rien, mais ce n’est pas bon
    Avec une latence moyenne à élevée, le comportement paraît imprévisible ou bogué. Des boîtes vides s’ouvrent, les liens ne réagissent pas comme attendu, et quand on enchaîne rapidement plusieurs actions, rien ne s’interrompt d’une manière intuitive. Tout semble juste décalé
    Aussi mauvais que puissent être les SPA, ici on a l’impression de s’éloigner encore un peu plus d’une UI native et naturelle

  • Si cet article refait surface maintenant, c’est parce que quelqu’un a publié la semaine dernière que Hey était lent à ouvrir des modales : https://x.com/noahflk/status/1795758603577545035
    Hey a été créé par DHH, qui a aussi créé Hotwire et Rails. Ensuite, cela a déclenché un vif débat mêlant la réponse de DHH affirmant que la vidéo originale avait été tournée sur un réseau bridé, les réactions disant que si charger une modale prend du temps c’est que Hotwire dépend trop du réseau, la défense de Rails/Hotwire, et l’opposition à cette approche. C’était un gros sujet sur Twitter la semaine dernière

    • Il est vrai que DHH a dit que la vidéo originale avait été tournée sur un réseau bridé
      L’auteur a aussi écrit qu’il l’avait « intentionnellement ralentie pour la démo » : https://x.com/noahflk/status/1795855075526471915. Il a précisé qu’il ne cherchait pas à montrer l’expérience de quelqu’un avec « un bon MacBook à SF et Internet en gigabit », mais plutôt celle d’une personne sur un Internet mobile lent et un ordinateur portable bas de gamme. Certains ont aussi fait remarquer que le SPA de Google Calendar était bien plus lent, et les options ne se limitent pas à « Internet gigabit à SF » et « 3G fortement bridée ». La publication originale prêtait fortement à confusion et relevait pratiquement du mensonge
    • Lien vers la réponse directe de DHH : https://x.com/dhh/status/1796163806650868149
    • Quand j’ai regardé Hey il y a environ un an, cela paraissait assez réactif, même depuis l’autre côté du Pacifique
      J’avais surtout été impressionné par la structure des pages. Par exemple, pour les menus contextuels en surcouche, ils appliquaient de manière progressive une combinaison details/summary/anchor, de sorte que même avec JavaScript désactivé ou si les assets ne se chargeaient pas, le contenu du menu apparaissait proprement dans une mise en page simple. Je me souviens aussi de plusieurs usages très soignés des Web API, et le code client n’était presque pas obfusqué et était accompagné de source maps. Je ne suis pas fan de DHH et je n’ai pas envie de suivre les dramas de la semaine, mais cette fois j’ai eu le sentiment que 37signals avait bien fait les choses
    • C’est déjà corrigé. Les mises à jour sont ici : https://x.com/dhh/status/1797370923391357143

  • J’ai créé il y a deux ans Swap JS, une implémentation plus minimaliste de la même idée : https://github.com/josephernest/Swap
    Je l’ai utilisé sur quelques projets et ça fonctionne bien