1 points par GN⁺ 1 시간 전 | 1 commentaires | Partager sur WhatsApp
  • htmx 4: the game est un jeu à 25 dollars qui permet de découvrir HTMX sur une Game Boy portable
  • Le jeu consiste à parcourir 4 niveaux pour collecter des cornichons
  • L’objectif principal est de réduire au minimum le JavaScript côté client et d’éviter le slop
  • À la fin, vaincre Warren permet de débloquer le code source de htmx 4.0
  • Comme il s’agit d’un produit fabriqué à la commande, les erreurs d’impression ou les problèmes de qualité visibles donnent lieu à un échange ou un remboursement, mais les retours classiques et les retours liés à la taille ne sont pas acceptés

htmx 4.0 sur Game Boy

  • htmx 4: the game est un jeu conçu pour faire découvrir HTMX sur une Game Boy portable, au prix de 25 dollars
  • À travers 4 niveaux, il faut collecter des cornichons tout en réduisant le JavaScript côté client et en évitant le slop
  • Vaincre Warren débloque le code source de htmx 4.0

Garantie qualité et conditions de retour

  • En cas d’erreur d’impression ou de problème de qualité visible, le produit est échangé ou remboursé
  • Comme il s’agit d’un produit fabriqué à la commande, les retours classiques et les retours liés à la taille ne sont pas autorisés

1 commentaires

 
GN⁺ 1 시간 전
Avis sur Hacker News
  • En utilisant htmx depuis 3 ans, j’ai découvert une nouvelle façon de créer des logiciels web lorsqu’il est associé à un langage de templates côté serveur.
    Plus impressionnant encore : la réactivité de l’exploitant de la boutique. Il y a quelque temps, je m’étais plaint sur Twitter qu’un mug de 8 onces était trop petit ; le lendemain, il a ajouté un énorme mug de 48 onces, et depuis je l’utilise tous les jours.

    • Je ne développe qu’occasionnellement des sites web pour des usages assez de niche, comme la gestion universitaire ou de conférences, mais j’ai été séduit par l’approche rapide et simple de HTMX.
      On peut créer rapidement des sites réactifs, peu coûteux pour les visiteurs, sans la lourdeur des déploiements centrés sur JavaScript ; les problèmes de compatibilité et les points de défaillance ont diminué, et le score de vitesse Google est passé de 60–80 à 100. Le débogage est aussi devenu plus simple, et le temps auparavant gaspillé en JavaScript peut désormais être consacré au design et à l’amélioration des fonctionnalités.
      La pratique consistant à laisser des sites web arbitraires exécuter, sans consentement de l’utilisateur, des calculs lourds et de l’analytics sur son appareil n’aurait jamais dû être autorisée au départ.
    • Il y a 3 ou 4 ans, nous avons adopté les templates côté serveur et htmx, et supprimé les deux tiers du JavaScript d’un SaaS B2B ; c’est devenu beaucoup plus simple.
      J’adhère à cette philosophie qui consiste à revenir à une manière simple de créer des applications web.
    • J’ai commencé à utiliser AWS Step Functions comme backend pour HTMX ; c’est difficile, mais amusant.
      De nos jours, Step Functions peut servir comme une sorte de moteur de templates texte étrange et rugueux, et j’envisage une couche DSL pour en lisser les aspects pénibles.
    • J’ai lancé un projet de plus avec htmx, et ce niveau de vitesse de développement paraît difficile à battre.
    • 1,25 litre, avec une sensibilité européenne, ce n’est pas un mug mais un seau.
  • L’ambiance de HTMX est excellente. C’est techniquement bon, simple et utile dans toutes sortes de situations, mais ça ne se prend pas trop au sérieux.
    Je l’utilise depuis l’époque d’intercooler.js, au travail comme dans des projets personnels, et je l’aime toujours autant. J’aime aussi le mug délirant avec la licorne aux yeux laser qui rappelle NROL-39 : https://swag.htmx.org/collections/octohorse, https://en.wikipedia.org/wiki/USA-247

    • L’écusson de mission NROL-39 fait partie de mes designs préférés. Allez chercher et lire les notes manuscrites sur le document d’approbation, c’est vraiment hilarant.
    • J’ai longtemps été opposé à HTMX, mais après avoir vu Claude l’utiliser dans un projet simple, et comme je suis aussi fatigué et lassé de React, ça commence maintenant à me sembler plutôt correct.
  • Au Big Sky Dev Con, quand le jeu Game Boy a été dévoilé, j’ai d’abord cru à une ruse avec un émulateur, puis quand on nous a dit que tout le monde pourrait repartir avec une vraie cartouche, j’en suis resté bouche bée.
    C’est l’une des opérations promotionnelles les plus amusantes que j’aie vues, et cela montre bien à quel point l’équipe HTMX accorde de l’importance à la finition et au fun dans tout ce qu’elle fait.

  • J’aime HTMX et je l’utilise dans plusieurs projets, mais je trouve amusant ce phénomène où l’ancien redevient nouveau.
    Les Web Forms du .NET Framework prenaient déjà en charge, en 2005, le rendu partiel de pages web avec UpdatePanel, et ils ont été beaucoup critiqués en dehors de l’écosystème .NET. HTMX est, dans une certaine mesure, une extension bien plus élégante et puissante de cette idée.

    • Même cette approche hérite en quelque sorte de la solution que proposait déjà Delphi IntraWeb, un ancêtre de C#, à l’époque de Delphi 7.
      À l’époque où l’on convertissait des PSD ajustés au pixel près en tableaux HTML ou en applets Flash, le concept a disparu parce qu’il cohabitait mal avec le styling ; mais quand on regarde de vieilles applications métier IntraWeb, on voit que les composants, les événements, etc., étaient déjà résolus bien avant qu’ils ne deviennent à la mode.
      J’aimerais voir réapparaître des outils RAD pour les stacks web modernes, mais le rythme de changement est trop rapide, et maintenant que le frontend et le backend sont des spécialités séparées, l’investissement semble moins rentable.
    • HTMX ressemble à la manière dont on créait des sites web autrefois avec la stack LAMP, mais avec une meilleure ergonomie de développement.
    • Après 10 ans à développer des frontends React, Angular et Vue, revenir à un rendu côté serveur traditionnel avec Ruby, Elixir, voire PHP, paraît au contraire naturel.
      Grâce à l’IA, il est devenu plus facile d’interagir avec un langage aussi peu agréable à regarder que PHP, tout en profitant de son écosystème profond, de sa vitesse d’exécution et de temps de build très courts. Même si je déteste la syntaxe de PHP et l’absence de typage statique, je suis plus productif que dans l’écosystème saturé de SPA.
      L’argument du rendu côté client, censé offrir une expérience applicative sans rechargement, relève en réalité de la logique des années 2010 ; le web et les technologies de navigateur ont déjà beaucoup évolué.
  • J’ai recréé plusieurs applications web open source de mon serveur domestique avec HTMX + Go + PostgreSQL.
    Elles sont légères et rapides sur desktop comme sur mobile, avec une complexité minimale, et le code est facile à comprendre et à modifier. Pour l’instant, je ne corrige que de petits bugs tous les quelques mois, et j’espère que, pour des applications mûres, l’intervalle entre mises à niveau indispensables pourra s’allonger jusqu’à plusieurs années, voire plusieurs décennies.

    • Je me demande s’il y a quelque chose d’open source publié. J’ai essayé rapidement la combinaison Go·htmx·PostgreSQL à quelques reprises, mais je n’ai pas eu un bon ressenti ; en particulier, les templates côté serveur de Go m’ont paru pénibles, et j’aimerais savoir si je suis passé à côté d’un bon pattern ou d’une bonne bibliothèque.
    • Même ça me paraît surconçu. Si le site n’a pas absolument besoin d’être disponible sans interruption pendant les changements de schéma, SQLite en mode WAL2 suffit.
      PostgreSQL aussi nécessite de la réplication et une procédure de bascule complexe si l’on veut éviter une interruption importante lors des montées de version, donc le choix n’est pas si simple.
  • J’utilise HTMX avec satisfaction depuis qu’il a commencé à se faire connaître, et j’ai aussi largement partagé l’article Grug ; grâce à cette culture qui maintient le développement logiciel amusant, j’ai acheté ce produit sans hésiter.

  • Je me demande si Grug-brained developer et HTMX ont été créés par la même personne.

    • Oui.
    • Il a aussi écrit le livre Lulu.
  • HTMX reste au final une bibliothèque JavaScript, et je n’aime pas le fait qu’elle n’offre pas suffisamment de comportement de repli automatique pour les environnements où les scripts sont désactivés.
    À cause de cela, les développeurs finissent par vouloir tout gérer avec HTMX, même les pages de contenu statique. Je cherchais PunkwebBB, basé sur Python, pour éviter la charge de PHP et MySQL en hébergeant un forum à l’ancienne, mais en désactivant les scripts, certains boutons ne faisaient rien, alors même que le projet utilisait HTMX sans nécessité fonctionnelle.
    Le volume de travail pour forker le projet et retirer le JavaScript inutile étant trop important, je suis finalement en train de créer moi-même un forum sans JavaScript basé sur Python Django.

    • Mon site Next.js fonctionne même JavaScript désactivé, avec des liens et du HTML rendus côté serveur. Les outils exécutés côté client s’arrêtent, mais les pages qui peuvent être statiques restent statiques.
      Cela dit, je viens seulement de découvrir qu’après l’introduction récente des composants de cache, cette propriété avait régressé, ce qui est frustrant.
    • Toute la conception de HTMX ressemble à une forme de comportement de repli automatique. Il suffit de concevoir le HTML envoyé initialement pour qu’il fonctionne correctement avec les navigateurs qui ne comprennent pas des attributs comme hx-get ou hx-post.
    • C’est pourquoi je préfère Turbo(https://turbo.hotwired.dev/).
      Turbo suit une philosophie d’amélioration progressive : partir d’un HTML correct, puis y ajouter des comportements enrichis. HTMX, comme React, est une bibliothèque JavaScript, ce qui n’est pas un problème en soi, mais il est plus facile avec elle de tomber dans l’antipattern qui consiste à tout faire dépendre de JavaScript.
      Aujourd’hui, l’argument selon lequel le site doit fonctionner sans JavaScript est moins fort que le fait qu’un HTML sémantique rendu côté serveur est important pour l’accessibilité, le SEO, les LLM et les outils d’automatisation. On peut produire un excellent HTML avec HTMX, mais il faut de la discipline et de l’expérience pour se rendre compte qu’on n’est pas en train de construire silencieusement une application JavaScript dans des attributs HTML.
  • htmx 4.0 sort sous forme de jeu pour Game Boy et Game Boy Color.
    C’est un vrai jeu inspiré de Mario Bros. : vous traversez quatre niveaux répartis sur trois biomes pour finalement affronter, dans l’usine à slop, le boss Warren Buffering, rival en ligne mais ami dans la vraie vie. En le battant, le code source de htmx 4.0 est débloqué.
    Il a été réalisé directement avec GB Studio, fortement personnalisé par Stephen Mitchell(scum), et un making-of sera publié prochainement. Jarason Banes s’est occupé de la fabrication des cartouches et du design de la jaquette, tandis qu’Ash(https://www.fiverr.com/ae1996/) a réalisé l’illustration de la jaquette et celle de la couverture souple de https://hypermedia.systems.

    • Je suis le créateur de GB Studio. C’est génial de voir ce projet l’utiliser, et je travaille aussi sur des fonctionnalités pour la prochaine version : https://www.youtube.com/watch?v=q8UKwV1gJAI
    • Si le moteur sonore intégré de GB Studio a été utilisé, c’est moi qui ai écrit ce code. C’est toujours un plaisir de voir mon code apparaître dans ce genre de projet.
    • J’ai commandé la cartouche et d’autres produits, et je compte m’y mettre dès que https://brickboy.xyz/ arrivera.
    • J’ai hâte de voir la première vidéo de déballage, gameplay et critique.
    • Je me demande s’il s’agit d’une vraie cartouche physique, et comment on récupère le code source à la fin.
      J’aimerais savoir si cela affiche un mot de passe pour le dépôt Git, ou si c’est une sorte de NFT donnant accès aux sources.
  • Un thread HTMX où aucun critique ne débarque pour expliquer pourquoi HTMX ne va pas, c’est surprenant.
    Même les fans de React semblent obligés de reconnaître que la sortie sur Game Boy est un coup réussi.