Datastar - un framework hypermédia léger pour créer des applications web interactives
(data-star.dev)- 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
<script type="module" src="https://cdn.jsdelivr.net/gh/starfederation/[email protected]/bundles/datastar.js"></script>
- 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!')"
- Exemple :
- L’attribut
data-onpermet 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 :
Si le serveur renvoie un fragment HTML, Datastar remplace automatiquement l’élément<button data-on-click="@get('/endpoint')">Open the pod bay doors, HAL.</button> <div id="hal"></div>id="hal"
Streaming basé sur les Server-Sent Events (SSE)
-
Le serveur peut envoyer l’événement
datastar-patch-elementspour 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
PatchElementsouServerSentEventGenerator
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
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 :
I switched from Htmx to Datastar (octobre 2025, 223 commentaires)
https://news.ycombinator.com/item?id=45537372, je réfléchissais encore à l’endroit où l’inclure, mais cela a été fusionné ici
Ancien fil : Datastar: Web Framework for the Future? (avril 2025, 155 commentaires)
Merci à dang, et je me demande s’il mémorise séparément les articles liés ou s’il utilise un outil particulier
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
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/