16 points par GN⁺ 2025-10-12 | 1 commentaires | Partager sur WhatsApp
  • Datastar est un framework léger qui permet de créer aussi bien de simples sites web statiques que des web apps collaboratives en temps réel, avec un simple ajout d’une balise script dans le HTML pour démarrer
  • Il adopte une approche hypermedia-first qui étend le HTML afin de permettre la création d’interfaces utilisateur interactives centrées sur le backend
  • Comme htmx, il apporte la réactivité côté backend, tout en prenant aussi en charge la réactivité côté frontend à la manière d’Alpine.js, le tout sans package npm ni dépendance
  • Côté frontend, les comportements réactifs sont implémentés via les attributs standard data-*, tandis que le backend effectue les modifications du DOM et les changements d’état à l’aide d’événements
  • Avec des mises à jour en temps réel basées sur SSE (Server-Sent Events) et des SDK pour plusieurs langages, il vise à simplifier le développement de web apps réactives pilotées par le backend

Aperçu de Datastar

  • Datastar est un framework hypermédia qui étend le HTML, conçu pour créer des web apps interactives en temps réel en manipulant directement le DOM depuis le backend
  • Côté navigateur, il suffit de charger un script de 10,7 KB pour activer toutes les fonctionnalités, sans outil de build ni installation de framework
  • Héritant des principes de Hypermedia Systems, le serveur pilote l’état de l’interface, et le client le reflète de façon réactive
  • Les mises à jour de données, changements d’état et patchs du DOM sont traités via des événements backend, ce qui minimise la logique frontend

Installation

  • La méthode la plus simple consiste à ajouter le script suivant via un CDN
  • Il est aussi possible de télécharger directement le fichier ou d’utiliser le bundler Datastar pour générer son propre bundle
  • Aucune installation npm ni configuration d’environnement Node n’est nécessaire

Attributs data-* et réactivité

  • Le cœur du système consiste à définir les comportements de manière déclarative via les attributs data-* du HTML
    • Exemple : data-on-click="alert('Hello!')"
  • L’attribut data-on permet de spécifier une expression Datastar à exécuter lorsqu’un événement donné se produit, et du JavaScript classique peut aussi y être utilisé
  • Une extension VSCode dédiée et un plugin IntelliJ fournissent l’autocomplétion et la prise en charge de la syntaxe

Patch du DOM piloté par le backend

  • Datastar fonctionne selon une approche où le serveur pilote le frontend
    • Lorsque le serveur envoie un fragment HTML, Datastar le fusionne dans le DOM via une stratégie de morphing
    • Le morphing met à jour uniquement les parties modifiées afin de préserver l’état et d’améliorer les performances
  • Exemple :
    <button data-on-click="@get('/endpoint')">Open the pod bay doors, HAL.</button>  
    <div id="hal"></div>  
    
    Si le serveur renvoie un fragment HTML, Datastar remplace automatiquement l’élément id="hal"

Streaming basé sur les Server-Sent Events (SSE)

  • Le serveur peut envoyer l’événement datastar-patch-elements pour mettre à jour le DOM en temps réel

  • L’exemple suivant affiche une réplique de HAL puis la réinitialise après 1 seconde

    event: datastar-patch-elements  
    data: elements <div id="hal">I’m sorry, Dave. I’m afraid I can’t do that.</div>  
    
    event: datastar-patch-elements  
    data: elements <div id="hal">Waiting for an order...</div>  
    
  • Pour cela, Datastar fournit des SDK pour de nombreux langages

    • Clojure, C#, Go, Java, Kotlin, PHP, Python, Ruby, Rust, Node.js
    • Chaque SDK émet des événements de patch du DOM via des classes comme PatchElements ou ServerSentEventGenerator

Datastar Inspector et outils

  • En plus des outils de développement du navigateur, Datastar Inspector permet de visualiser les événements SSE
  • En plus de la documentation officielle, le projet propose également une DeepWiki générée par IA, des exemples de code pour LLM et une documentation en page unique, parmi d’autres ressources

Conclusion

  • Datastar représente une approche moderne qui simplifie le développement d’applications hypermédia centrées sur le HTML
  • Plus léger que les frameworks SPA classiques, il offre une expérience de développement réactive équilibrée entre backend et frontend
  • Il convient bien aux projets nécessitant du streaming en temps réel, un contrôle de l’interface centré sur le serveur et un déploiement sans dépendances

1 commentaires

 
GN⁺ 2025-10-12
Avis Hacker News
  • Les responsables de Datastar ont des convictions et une philosophie très claires, et ce sont des personnes formidables qui consacrent généreusement du temps même aux débutants. Cela a été oublié au milieu de la controverse autour de la version Pro, mais ce n’est en aucun cas une stratégie de monétisation, et l’entreprise est enregistrée comme organisme à but non lucratif. Seules des fonctionnalités dont une minorité a besoin ont été placées en Pro, comme moyen de contrôler efficacement l’augmentation de la charge de support provoquée par le petit groupe qui souhaite précisément ces fonctions et pose l’essentiel des questions. C’est plutôt une approche innovante et équitable qui (a) signale qu’il s’agit de fonctionnalités « piégeuses » avec lesquelles il faut être prudent, (b) fait payer une petite somme aux utilisateurs qui ont besoin du plus de support ou tirent énormément de valeur de Datastar, et (c) permet de consacrer davantage de temps à l’ensemble de la communauté, avec un effet positif

    • Si des fonctionnalités comme data-animate, data-on-resize ou data-scroll-into-view sont des « pièges », alors elles sont mal conçues. Je ne pense pas non plus que ce soient des fonctions dont seule une minorité a besoin. Qu’ils fassent payer ce qu’ils veulent, pas de problème, mais il n’y a pas besoin d’inventer des excuses pour ça

    • Je me demande vraiment si la fonctionnalité copy-to-clipboard génère une charge de support si importante. Si le niveau de Datastar est réellement à ce point médiocre qu’il faut beaucoup de support pour qu’une fonction aussi simple marche correctement, j’ai du mal à être d’accord

  • Si vous pensez que Datastar n’est pas suffisant pour le temps réel / la collaboration / le multijoueur, ou que les fonctionnalités Pro sont indispensables, regardez ces 3 démos qui tournent sur un VPS à 5 dollars et ont tenu sur la page d’accueil de HN sans fonctionnalités Pro : cela montre à quel point l’ingénierie de Datastar est impressionnante

    • https://checkboxes.andersmurphy.com/

    • https://cells.andersmurphy.com/

    • https://example.andersmurphy.com/ (jeu de la vie multijoueur)
      Dans les exemples checkboxes/cells, le rendu de la vue est adaptatif, ce qui permet de dézoomer assez loin, et le défilement virtuel applique aussi du back pressure

    • Peut-être qu’elles ont tenu sur la page d’accueil de HN, mais il est écrit en énormes lettres sur le premier écran « bring your own backend », donc ce n’est pas grâce à Datastar qu’elles ont tenu

  • Informations sur les fils de discussion HN connexes en cours :

  • Je ne comprends pas vraiment pourquoi la communauté est aussi hostile. Datastar est en grande partie open source, fonctionne avec n’importe quel langage, et c’est aussi un projet intéressant par sa réflexion sur le financement du développement. Je trouve naturel qu’ils fassent avancer leur propre projet à leur manière. J’ai bien envie de bricoler avec en golang, et merci pour tout ce travail. Je n’ai qu’un seul retour : dans mon pays, 299 dollars, c’est vraiment une somme énorme, et il se peut que certaines fonctionnalités Pro soient indispensables, donc le prix est trop lourd. J’aimerais qu’ils envisagent une tarification dynamique par pays comme Steam, ou une forme de soutien par don. Des choses comme les animations sont gratuites dans sveltekit ; ce n’est pas que je veux tout avoir gratuitement, c’est juste que je n’en ai vraiment pas les moyens. J’aimerais qu’ils facturent davantage les entreprises et moins cher les développeurs solo. Je n’ai jamais payé pour une communauté ou un projet en ligne jusqu’ici, mais pour Datastar, je serais prêt à soutenir à hauteur de 5 à 10 dollars. J’aimerais simplement que le tarif solo descende au niveau d’un jeu Switch (silksong). C’est un projet vraiment formidable, donc c’est dommage que la réaction de la communauté soit à ce point critique

    • C’est le seul commentaire qui me semble être une critique raisonnable dans toute la discussion jusqu’ici. 299 dollars, c’est réellement inaccessible pour beaucoup de monde. Cela dit, cela peut aussi être une petite somme comparée à la valeur fournie par des développeurs qui vivent dans des pays au coût de la vie élevé. L’idée d’un système de prix par pays est bonne, mais sa mise en œuvre est complexe et le bénéfice réel pourrait être faible. Comme les fonctionnalités open source gratuites fournissent déjà plus de 95 % de la valeur et des capacités, la majorité des gens qui n’ont pas vraiment besoin de la licence Pro devraient simplement utiliser librement la version gratuite, apprendre avec ou en tirer profit

    • Voici d’où part ma critique

      • La page d’accueil ne mentionne absolument pas Pro, je ne l’ai découvert qu’en fouillant dans la documentation. Ça donne une impression d’appât
      • Pro regroupe de vraies fonctionnalités, pas seulement du support ou des exemples
      • Si on dépend des fonctionnalités Pro, on devient dépendant de Datastar et la maintenabilité reste liée au fournisseur
      • Sans Pro, le site ne fonctionne tout simplement pas, donc le verrouillage fournisseur devient un problème encore plus important
      • Il n’existe pas de démo d’essai pour voir ce qu’on achète avec Pro, comme on peut le faire dans le navigateur avec Alpine.js ou React Flow Pro
      • Même si on reçoit le code source, on ne peut pas partager les améliorations
      • Le problème n’est pas le prix mais la structure et la valeur ; pour certains ce sera peu cher, pour d’autres très cher
      • Exemples de modèles Pro pas mauvais à consulter : Alpine.js Pro, React Flow Pro
    • Même une petite entreprise doit assurer le support elle-même ; dans des pays où le coût de la vie est élevé, 5 dollars ne permettent même pas de traiter un seul ticket de support

  • Je développe depuis quelques mois un frontend basé sur Go et Templ avec Datastar. J’aime beaucoup la fonctionnalité @actions et la façon dont la page se met à jour selon les réponses. En revanche, je m’interroge encore sur les signals. C’est très bien pour un champ unique ou une liste déroulante, mais mon backend expose une API de style Kubernetes, et quand j’essaie de stocker une ressource JSON dans un signal, la manière dont Datastar découpe la structure en sous-signaux s’accorde mal avec ce cas. En particulier, des structures comme les labels Kubernetes, où les clés ont un préfixe de hostname, sont totalement ingérables, et les signals deviennent chaotiques. Le data binding fonctionne bien avec des chemins de clés simples, mais pas avec des chemins qui nécessitent des index ou des clés de hostname. En plus, les règles de conversion automatique des attributs HTML en JS (snake → camel, etc.) et le traitement des modifiers introduisent souvent des erreurs, ce qui complique les choses. Malgré cela, j’apprécie le fait de réunir les fonctionnalités de HTMX/Alpine dans une approche hypermedia, et j’apprécie aussi de pouvoir éviter l’écosystème NodeJS. Le wire format a changé une fois pendant la RC, et comme j’utilisais Fiber et faisais l’implémentation directement sans le SDK Go, la mise à jour a été pénible. Mais je pense que ce changement de format allait dans le bon sens. L’équipe va dans une bonne direction, donc j’espère que ça continuera à progresser

  • Les idées de Datastar me paraissaient vraiment excellentes, au point que j’ai envisagé de l’adopter. Cela dit, le fait de limiter la version open source pour qu’elle ne concurrence pas les fonctionnalités Pro m’inquiète : cela pourrait être la voie rapide vers un hard fork. L’écosystème n’est pas non plus si vaste, donc les raisons de changer existent déjà
    [edit: un modèle open core qui garde certains plugins fermés peut être tout à fait raisonnable, et même si ce n’est pas le cas, les alternatives ne manquent pas ; j’espère que les développeurs et les utilisateurs de Datastar réussiront]

    • Si vous vous inquiétez d’un hard fork, il suffirait de forker les plugins de l’époque pré-Pro et de les adapter à la version pro actuelle de Datastar ; ce serait utile à tout le monde. C’est très facile, ce sont de petits morceaux de code d’environ 50 lignes

    • Dire qu’ils « mettent des limites » est excessif : les attributs/événements réservés à Pro sont peu nombreux, et ce ne sont pas des fonctionnalités essentielles. En réalité, il suffit souvent d’un peu de JS envoyé depuis le serveur pour les remplacer. Voir la liste détaillée : https://data-star.dev/reference/datastar_pro

    • Je recommande vraiment un fork, j’aimerais que quelqu’un le fasse

  • Je suis peut-être trop habitué à l’écosystème React, mais dès qu’on veut faire quelque chose d’un peu complexe, cette approche me paraît logiquement beaucoup plus difficile. Sauf si j’ai mal compris l’explication, Datastar suit un modèle backend-frontend où le backend renvoie du HTML, et pour l’avoir déjà pratiqué autrefois, c’est une approche à laquelle je n’ai vraiment aucune envie de revenir. En particulier, pour les utilisateurs avec une connexion lente (il y en a encore beaucoup : DSL, anciens satellites, 2G, etc.), recevoir plusieurs gros morceaux de HTML au lieu de plusieurs petits JSON va probablement dégrader fortement les performances perçues

    • D’après mon expérience, utiliser une app React en 2G/3G aboutissait souvent à une page qui ne s’affichait tout simplement jamais, alors qu’avec du HTML reçu d’un coup, le contenu apparaissait généralement en 1 à 2 secondes. Les ingénieurs recréent souvent arbitrairement des timeouts ; la détection de progression, je la fais au niveau du socket, mais dans l’application il n’y a aucune sensation de progrès. Il ne faudrait pas chercher à tout prix à donner une impression de « rapidité »

    • Le modèle « le backend renvoie du HTML », c’était déjà celui des sites web à l’époque des modems 56k, et je me souviens qu’on faisait alors des mises en page avec des dizaines de tables imbriquées

    • Le frontend couvre un spectre très large. Pour un blog personnel ou une boutique, avec beaucoup de contenu statique, un besoin de chargement rapide et peu d’interaction, des outils de la famille htmx sont bien adaptés. Mais si vous voulez construire une app du niveau de Figma ou Discord, cette approche ne suffit pas. Au plus haut niveau, le DOM n’est qu’une prison, et seule la combinaison canvas + calcul GPU est satisfaisante

    • Si l’objectif est du totalement hors ligne, alors évidemment il n’y a pas vraiment d’autre solution. Mais la plupart des sites n’ont pas besoin d’un état persistant, donc un cache de page ou un simple état d’événements suffit souvent largement. Si on fait tourner le datastar js sdk dans un service worker et qu’on synchronise seulement l’état indispensable avec le stockage du navigateur, il peut même jouer le rôle du backend. Même sur une connexion lente, si on compresse fortement le flux SSE, le taux de compression dépasse facilement 90 % malgré la redondance d’information. Et comme un internet lent va souvent de pair avec des appareils lents, Datastar est bien plus léger que React, le CSS-in-JS et autres approches lourdes, avec une énorme simplification pour presque aucun sacrifice fonctionnel

  • Ce n’est pas un modèle particulièrement nouveau. On est déjà passés par là à l’époque du passage de DHTML à XHR, et il a été largement abandonné à cause de divers compromis. Même des techniques récentes comme le patching du DOM finissent par retrouver les mêmes problèmes : couplage fort, fragilité, volume important, latence. Datastar ressemble surtout à une solution pour réduire les coûts de développement dans de petites entreprises, pas à une percée qui repousse les limites techniques. Ce n’est pas mauvais, mais cela donne au final l’impression que l’histoire se répète

    • En tant qu’auteur de Datastar, le fait que rien ne soit nouveau est précisément l’objectif. J’ai regretté qu’après la bonne époque où jQuery n’avait qu’un léger impact sur la page, les SPA aient voulu tout faire côté frontend, au point d’effacer le fait fondamental que c’est le backend qui détient l’état. Ce que je cherche n’est pas l’innovation mais un retour à la normale

    • J’ai l’impression qu’Astro a déjà résolu ce problème, non ?

  • J’aime tellement la vidéo (le film) en bas de page qu’elle me donne envie de l’utiliser dans mon prochain projet ; la partie « The planet uncomplicanus » m’a particulièrement marqué

  • J’aime aussi le résultat obtenu par https://www.zjax.dev/