• # htmx sucks

    Posté par  . Évalué à 1.

    N'y touchez pas. Si vous y touchez, le doute va s'insinuer en vous.

    • [^] # Re: htmx sucks

      Posté par  . Évalué à 2.

      Tu as un retour d'expérience plus précis à partager ?

      • [^] # Re: htmx sucks

        Posté par  . Évalué à 5.

        Je n'ai pas fait d'application "conséquente" avec HTMX. Mais étant un dev plutôt backend, je me suis retrouvé dans la proposition qui est faite. J'ai pû faire une application web de quelques écrans de gestion de ma collection de films avec intégration à IMDB. Ce de manière bien plus plaisante que avec n'importe quel framework frontend.

        J'ai utilisé Python+FastAPI+Pydantic+Jinja+Pug+HTMX.

        Mais si vous voulez quelque chose de sérieux, je vous invite à regarder cette vidéo. Toute la conférence est intéressante mais pour ceux qui sont intéressés par les chiffres, se rendre au timecode 17:58.

        En gros, sans perte de confort utilisateur, et même en l'améliorant côté perf, ils sont passé de 21kloc de JS à 6kloc et seulement de 500 loc à 1200 loc Python. Il explique aussi qu'un développeur peut maintenant prendre une feature de bout en bout, sans que le front doive attendre le back.

    • [^] # Re: htmx sucks

      Posté par  . Évalué à 3.

      Idem que au dessus !

      Ca fait un bon moment que je regarde ce truc et globalement, le principe me semble intéressant pour faire du AJAX like sans trop s’embêter.

      Mais en contrepartie, je ne suis pas du tout fan

      • de la surcharge des balises HTML
      • du mix balises HTML + instructions pseudo javascript
      <div hx-get="/messages"
    hx-trigger="load delay:1s"
    hx-swap="outerHTML"
>
</div>

      En fait, je suis curieux de savoir si le code produit pour une application un peu conséquente arrive à rester lisible et bien structuré.

      "Si tous les cons volaient, il ferait nuit" F. Dard

      • [^] # Re: htmx sucks

        Posté par  . Évalué à 1.

        du mix balises HTML + instructions pseudo javascript

        Ça ressemble plus à du html déclaratif qu'à du javascript pour moi. Par contre je trouve que quelque chose du style hx-trigger-delay="1s" aurait été plus cohérent.

        Le manque de consistance dans le nommage des triggers me pose plus soucis par contre :

        innerHTML
        outerHTML
        afterbegin
        beforebegin
        beforeend
        afterend

      • [^] # Re: htmx sucks

        Posté par  . Évalué à 5.

        Je ne sais pas ce qui est considéré comme une application conséquente mais je n'ai aucun mal à adapter mes applications classiques (SSR) à htmx.
        Par contre je pense qu'il ne faut pas tomber dans le piège d'en mettre de partout, j'utilise htmx uniquement quand c'est réellement utile voir indispensable. Sur linuxfr par exemple on pourrait l'utiliser pour la prévisualisation mais peu d'intérêt pour aller d'un journal à l'autre à mon avis.

        • [^] # Re: htmx sucks

          Posté par  (site web personnel) . Évalué à 10.

          Netbox utilise HTMX pour charger les formulaires des fenêtres modales.

          En fait, il y a tellement de gens qui présentent HTMX comme un remplaçant de React que ça donne une mauvaise image de la chose.

          Comparer HTMX et React c'est stupide.

          Pour comprendre l'intérêt de HTMX, il faut faire un peu le point sur l'histoire du web dev :

          • On commence avec du contenu statique, HTML / CSS servi par un serveur HTTP
          • On génère ce HTML dynamiquement côté serveur (CGI Perl, CGI PHP, framework Python/Ruby/…, …) à chaque requête
          • On a besoin d'interactivité côté client (fenêtres modales, formulaires dynamique, notifications, …), c'est là ou on introduit Javascript
          • La compatibilité entre navigateurs est un problème, d'où jQuery
          • C'est galère à organiser le code, du coup on créé des frameworks JS
          • Ce qu'on veut en fait, c'est faire nos propres composants HTML, d'ou React/Vue/WebComponents/…
          • Il s'avère qu'autant de JS côté client c'est lent, alors on veut du SSR (rendu côté serveur)

          Et on est revenu au point de départ, un serveur qui retourne du HTML. A ce moment là, a-t-on besoin d'un framework JS ?

          On a désormais les WebComponents pour créer de l'intéractivité côté client uniquement là ou il y en a besoin, HTMX 2.0 améliore sa compatibilité avec ces derniers justement (un meilleur support du shadow DOM).

          HTML5 se dote d'éléments comme <summary> ou <dialog> rendant certains patterns en JS (comme la fenêtre modale) obsolète.

          La proposition d'HTMX c'est de continuer à faire évoluer le HTML pour devenir le langage du web, au lieu que cela soit JS (ils sont d'ailleurs en discussion informelle avec des développeurs de navigateurs ainsi que le W3C pour incorporer certaines fonctionnalités de HTMX dans le standard, et donc implémenté par le navigateur). Il faut donc l'utiliser là ou ça fait sens. Si on se mets à écrire :

          <div hx-get="/mycomponent" hx-trigger="load"></div>

          C'est que l'on n'a rien compris à HTMX.

          https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

          • [^] # Re: htmx sucks

            Posté par  . Évalué à 5.

            La proposition d'HTMX c'est de continuer à faire évoluer le HTML pour devenir le langage du web, au lieu que cela soit JS

            Merci, c'est bien ce qu'il me semblait, mais là c'est clairement exprimé.

            et c'est bien le sentiment que cela m'a laissé après avoir lu quelques articles que Le créateur d'htmx a rédigé pour éclairer sa démarche:
            https://htmx.org/essays/

            Globalement, j'aime beaucoup l'approche

            "Si tous les cons volaient, il ferait nuit" F. Dard

            • [^] # Re: htmx sucks

              Posté par  . Évalué à 4.

              Comme Luc Skywalker, c'est exactement ce qu'htmx est pour moi, merci David pour cette explication simple et claire qui mérite un +10

          • [^] # Re: htmx sucks

            Posté par  (site web personnel) . Évalué à 4.

            Si on se mets à écrire : […] C'est que l'on n'a rien compris à HTMX.

            Pour information, c'est ce que j'avais tendance à faire à mes débuts avec HTMX.

            Je venais de passer 5 ans à splitter un backend monolithe en architecture micro service. Et j'étais hypé par la notion de "micro frontend", et je comprenais pas qu'on parlait de "micro frontend" pour des applications React/Vue, qui me semblaient être des monolithes modulaires (je n'ai rien contre cette architecture).

            Ma première impression de HTMX fut donc de fournir des bouts de frontend en provenance de serveurs distincts.

            Je vous dis pas la monstruosité d'over-enginering que j'avais pondu à l'époque (circa 2021, bien avant la hype récente de HTMX). Les bugs d'affichage impossible à debugguer car j'avais foutu un <body hx-boost="true">.

            En gros, j'essayais de faire une SPA (Single Page Application) avec HTMX, et c'est clairement pas le but du projet.

            Bref, j'avais rien compris à HTMX.

            Ensuite j'ai pris du recul, j'ai refait du Django sans API REST/JSON, template côté serveur, et tout le tralala.

            Et puis les rares moments ou je me suis dit "tiens, ça serait bien que le serveur puisse m'envoyer un peu de HTML à rajouter ici", c'est là que HTMX est venu à mon aide.

            Un cas d'usage que j'apprécie tout particulièrement désormais : Un système de notification.

            Faites un endpoint SSE (Server Sent Event) côté serveur, qui envoit le contenu suivant :

            event: notify
data: <p>some HTML for a notification</p>

            Côté client :

            <div class="notification-container" hx-ext="sse" sse-connect="/path/to/sse/endpoint" sse-swap="notify"></div>

            De la même manière, on peut créer un système de chat assez simplement :

            <div class="chat-container" hx-ext="sse" sse-connect="/path/to/sse">
  <div class="history" sse-swap="message"></div>
  <form hx-post="/send_message" hx-trigger="submit">
    <input name="message">
    <button type="submit">Send</button>
  </form>
</div>

            https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

          • [^] # Re: htmx sucks

            Posté par  . Évalué à 5.

            il y a tellement de gens qui présentent HTMX comme un remplaçant de React que ça donne une mauvaise image de la chose.
            Comparer HTMX et React c'est stupide.

            Ça se compare au sens ou c'est une alternative si tu dois faire une application web : tu peux faire du MPA, du MPA avec du jquery, du SPA avec un des 15 framework TS/JS qui existent, du SSR, du Phoenix/Liveview, du HTMX, du ELM, du Purescript, etc.

            C'est toujours intéressant de savoir les points forts et les points faibles de chaque approche.

          • [^] # Re: htmx sucks

            Posté par  . Évalué à 6. Dernière modification le 20 juin 2024 à 08:50.

            il y a tellement de gens qui présentent HTMX comme un remplaçant de React que ça donne une mauvaise image de la chose.

            Comparer HTMX et React c'est stupide.

            Comparer HTMX et React est stupide quand ils sont utilisés là où ils sont adaptés mais bien souvent React est utilisé là où HTMX aurait largement pu faire l'affaire en évitant une usine à gaz.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.