Présentation HN : HTMX Playground, implémenté à 100 % dans le navigateur

 (lassebomh.github.io)
6 points par GN⁺ 2024-01-09 | 1 commentaires | Partager sur WhatsApp
  • Un bac à sable de code qui permet de commencer immédiatement à expérimenter HTMX dans le navigateur, sans installation ni configuration locale
  • Dans server.js, il gère les endpoints et le rendu de templates, tandis qu’un serveur simulé dans le navigateur intercepte les requêtes HTMX
  • Le traitement des requêtes et l’approche par templates seront familiers aux utilisateurs de Django, et l’outil peut aussi servir à tester des bibliothèques autres que HTMX
  • Le partage se fait en exportant via « Copy as JSON », puis en saisissant l’URL raw d’un Gist dans « Load Playground »
  • Attention à l’absence de navigation entre pages, à la prise en charge mobile limitée et à la perte possible des mises à jour d’état de on.get("/") due au chargement initial de l’iframe

Un bac à sable HTMX exécuté dans le navigateur

  • HTMX Playground est un simple bac à sable de code permettant d’expérimenter HTMX sans installation
  • Il propose des exemples adaptés à partir des exemples d’origine de htmx.org
  • Il permet d’écrire du code dans le navigateur avec un flux proche de celui d’un backend
    • Définir des endpoints dans server.js
    • Rendre directement des templates
    • Un serveur simulé intercepte les requêtes sortantes de HTMX
  • Le traitement des requêtes et le moteur de templates ont une forme familière pour les utilisateurs de Django
  • Le projet lui-même n’est pas limité à HTMX et permet aussi d’essayer d’autres bibliothèques
  • Le code est disponible sur GitHub

Mode d’enregistrement et de partage, et limites connues

  • Enregistrement et partage

    • Cliquer sur « Copy as JSON » en haut à droite pour copier le contenu
    • Téléverser le contenu copié dans un Gist
    • Saisir l’URL raw dans « Load Playground »
    • Une fois l’URL de la page mise à jour, elle peut être partagée

  • Limites

    • Il n’y a pas de navigation entre pages
    • La prise en charge mobile est limitée
    • server.js peut conserver un état, comme dans l’exemple Click to Edit
    • Si l’état est mis à jour dans la vue on.get("/"), cette mise à jour peut disparaître
      • Car le chargement initial de la page est d’abord récupéré dans une iframe distincte avant de mettre à jour l’iframe affichée à l’écran

  • Bibliothèques utilisées

    • Svelte
    • Ace
    • PollyJS
    • Nunjucks

À lire aussi

1 commentaires

 
GN⁺ 2024-01-09
Avis de Hacker News

  • Je suis le créateur de htmx, et je trouve ça vraiment génial ; merci beaucoup de l’avoir fait

    • Je me demande s’il existe une façon d’utiliser HTMX en minimisant les changements côté serveur
      Sur une page existante, quand on remplit et soumet un formulaire, la réponse revient sous forme de page complète ; si l’on pouvait dire à htmx « une page complète va revenir, mais ne mets à jour que #my-form », il ne serait pas nécessaire d’ajouter côté serveur des branches du type « si c’est une requête htmx »
      Ce serait utile pour ceux qui veulent que leur site fonctionne sans JavaScript, et cela permettrait aussi de gérer plusieurs fonctionnalités — commentaires, abonnements e-mail, boutons J’aime — avec un seul endpoint backend
    • Je me demande si tu as entendu parler de Phoenix LiveView, et si le concept est similaire à htmx

  • J’ai envisagé d’utiliser HTMX sérieusement, mais je crains que le vivier de développeurs soit trop réduit, ce qui compliquerait le recrutement
    J’étais habitué à des frameworks propriétaires proches de Thymeleaf, comme l’isml d’Intershop, et récemment je comptais passer à une stack frontend Angular parce qu’il est plus facile de recruter des développeurs frontend dédiés
    Une approche comme htmx peut devenir complexe, les développeurs n’ont pas envie de se battre contre un monstre de spaghetti, et si le frontend ne fait que produire du HTML tandis que le backend doit tout assembler, les développeurs backend peuvent devenir le goulot d’étranglement
    Je me demande si HTMX a pris en compte ces pièges, et comment il y répond

    • htmx est très intuitif à apprendre ; si ce n’est pas quelqu’un issu d’un bootcamp de code qui n’a appris que React, un développeur connaissant de vrais sujets d’informatique devrait pouvoir être productif en une semaine au maximum
    • La réponse est simple : HTMX s’apprend en une demi-journée au plus, et probablement encore plus vite
      Cela dit, HTMX ne résout pas toutes les situations ; il y a aussi des cas où l’on a besoin d’une application monopage utilisant un framework JavaScript
    • C’est intéressant de mentionner Angular puis de dire que htmx peut devenir complexe ; on dirait que la perception de la complexité est différente
      Les frameworks comme Angular apportent de la structure, mais la complexité reste là, et elle peut même être bien plus grande
      Au final, ce qu’il faut, c’est un développeur frontend qui connaît bien la stack web — JavaScript, CSS, HTML, API du navigateur — ; cette personne saura choisir les outils et frameworks adaptés à la tâche, et apprendra très vite quelque chose comme HTMX
    • Rien n’est aussi convaincant que le succès, et htmx s’est classé 2e dans la catégorie frameworks des JS Rising Stars 2023
      https://risingstars.js.org/2023/en#section-framework
      Juste derrière React, et devant Vue, Svelte et Angular ; de ce point de vue, l’avenir semble donc prometteur. Cela dit, je m’attends à ce que son classement baisse une fois l’enthousiasme initial retombé
      htmx est assez simple, et la plupart des développeurs web peuvent l’apprendre en une journée environ, mais son mode de développement pousse l’organisation vers un paradigme full-stack où le développeur possède une fonctionnalité de bout en bout ; il faut donc un changement de mentalité non seulement chez les développeurs, mais aussi chez les PM et les architectes
      Il existe aussi un livre gratuit en ligne : https://hypermedia.systems
      En plus de la documentation (https://htmx.org/docs, environ une heure de lecture), il y a des articles qui traitent des questions philosophiques et pratiques autour de htmx et de l’hypermédia en général : https://htmx.org/essays
      htmx repose sur très peu d’idées de base, et il cherche à être « extensible », avec des comportements utiles comme le chargement différé réalisables au moyen de deux attributs : https://htmx.org/examples/lazy-load
      En même temps, il offre des hooks comme les événements ou les filtres d’événements, ainsi que des fonctionnalités plus profondes, ce qui permet d’obtenir le comportement voulu quand on creuse davantage
      Le code spaghetti est un risque permanent dans tout développement logiciel, et personnellement je n’ai jamais été convaincu que les bibliothèques d’applications monopages l’empêchaient
      Avec htmx, il vaut mieux concentrer l’effort sur le backend et bien décomposer l’application avec les outils fournis par l’environnement côté serveur
      Comme htmx permet de choisir n’importe quelle technologie serveur, il offre davantage d’options et de paradigmes pour organiser la logique applicative qu’une application monopage, où une grosse application JavaScript/TypeScript existe déjà côté frontend et pousse souvent le backend dans la même direction
      J’ai aussi essayé de résumer ici pour quels types d’applications htmx est un bon choix : https://htmx.org/essays/when-to-use-hypermedia/
      htmx est un bon outil dans de nombreux cas, mais ce n’est qu’un outil, pas une solution miracle pour le développement web
    • Pour le recrutement, il s’agit plutôt de rechercher des compétences backend qu’une expérience HTMX
      En gros, on recrute un développeur backend capable de faire un peu de frontend ; il n’a pas besoin d’avoir HTMX sur son CV, seulement quelques bases comme JavaScript
      La plupart des développeurs web remplissent cette condition

  • J’utilise MapLibre avec Django et htmx ; je devrais mettre en ligne un exemple pour pouvoir le partager avec d’autres

    • J’ai fait quelque chose de similaire avec https://ratethispad.com, et c’était assez amusant à construire
      Personne ne l’utilise, mais j’aimerais bien voir ce projet aussi
    • Je n’ai rien que je puisse partager publiquement, mais j’ai travaillé avec Django, htmx, SQLAlchemy, Plotly, et j’ai trouvé l’ensemble assez robuste
    • Si tu veux porter davantage d’exemples officiels, crée une issue avec le lien et on pourra l’ajouter au dépôt

  • Monaco ne fonctionne pas sur mobile par conception, donc je crois qu’ils utilisent Ace sur mobile
    C’était du moins le cas la dernière fois que j’ai consulté l’issue GitHub
    [0] https://github.com/Microsoft/monaco-editor/issues/246

  • Est-ce que ça prend aussi en charge ActiveX ?

    • Ça me rend triste d’être assez vieux pour comprendre cette blague
    • Ça m’a rappelé HP Quality Center
      Dans les premières versions, toute l’UI était en ActiveX, et je garde le souvenir de tas de barres de progression installant des DLL

  • On pourrait aussi fabriquer ce genre de chose avec un Service Worker, et permettre de naviguer en ouvrant plusieurs pages dans d’autres onglets
    Ça ne devrait pas être si difficile, et pour générer les pages on pourrait utiliser du JavaScript pur ou ce que l’utilisateur veut

  • Puisque c’est fait avec Svelte, où sont passés les puristes du MPA et leurs fourches ?

    • Je suis un puriste du MPA, mais je reconnais tout à fait qu’il existe une catégorie d’applications pour lesquelles une application monopage est le meilleur choix

  • J’aime le concept de htmx et j’ai commencé à lire le livre aujourd’hui, mais chaque fois que je me dis qu’il faudra peut-être un jour prendre aussi en charge des applications mobiles natives, ça me fait hésiter à l’utiliser
    Dans ce cas, j’ai l’impression qu’il faudrait réécrire non seulement le frontend, mais aussi une bonne partie du backend
    Je connais hyperview.org, mais une application React Native ne suffit pas pour les cas d’usage qui m’intéressent

  • Je me demande s’il y a des gens qui créent des apps hors ligne avec un serveur virtuel défini dans un Service Worker et un modèle de requêtes-réponses HTML/HTMX

    • Bonne question
      J’aime htmx, mais je n’ai pas pu l’utiliser dans des situations où il fallait aussi fonctionner hors ligne
      Si on pouvait exécuter tel quel le code serveur dans un worker, ce serait un hack formidable
    • Je construis un serveur/backend pour htmx qui tourne comme service local à côté du navigateur
      En théorie, n’importe quelle pile serveur auto-hébergeable peut convenir
      L’objectif est de produire un binaire unique sans dépendance à des services externes, et j’utilise Go
      Beaucoup de composants sont déjà bien en place, comme un service local avec mise à jour automatique et une base de données répliquée, et il est aussi facile de compiler en cross-compilation pour plusieurs systèmes d’exploitation et architectures
      Comme alternative au fait de tout mettre dans le navigateur, cette approche me semble assez pertinente, à condition de pouvoir lancer un processus séparé
      Cela dit, j’aimerais bien que Go ait une gestion des permissions à la Deno
    • Il existe un exemple concret : https://github.com/jon49/htmx-todomvc
      J’utilise ce pattern pour toutes mes applis personnelles, avec toutefois une petite bibliothèque maison de type htmx
      Passer à HTMX ne me semblerait pas très difficile

  • Je me demande si transposer HATEOAS vers des applications desktop ou mobiles serait une bonne idée ; ça pourrait faire une expérience intéressante

    • Si tu parles de mobile natif, j’ai utilisé HATEOAS dans du code natif vers 2013
      Ça fonctionne bien, mais ce n’est pas aussi flexible que le web, et il faut développer chaque écran linkable de manière strictement boîte noire
      La tentative était intéressante, mais je ne suis pas sûr de la valeur que ça aurait en production
    • Je n’ai vu HATEOAS que comme concept abstrait, et je n’ai jamais eu l’impression, dans une UI réelle, que « les interactions utilisateur sont vraiment meilleures »
      REST a été bienvenu parce qu’il a simplifié les monstres SOAP, mais il a aussi apporté pas mal de dogmatisme
      Je comprends l’objectif fondamental de REST, puisqu’il aligne des concepts, des données et une architecture de services qui sont naturels pour l’utilisateur
      Mais HATEOAS m’a semblé être le résultat d’une envie d’avoir plus de dogmatisme et d’esbroufe en réunion d’architecture, plutôt que de se concentrer sur la question de savoir si l’expérience utilisateur s’améliore grâce au modèle
      Je me demande s’il existe un exemple d’UI qui montre pourquoi HATEOAS devrait être pris comme principe de base
      En gros, chaque page a des liens vers « ce qu’il faut faire ensuite », et HATEOAS me donne l’impression d’être une manière tape-à-l’œil d’apporter ce modèle d’état aux appels de services REST
    • Je me demande déjà si HATEOAS est une bonne idée
    • C’est ici : https://hyperview.org/