Datastar – leichtgewichtiges Hypermedia-Framework zum Aufbau interaktiver Web-Apps

 (data-star.dev)
16 Punkte von GN⁺ 2025-10-12 | 1 Kommentare | Auf WhatsApp teilen
  • Datastar ist ein leichtgewichtiges Framework, mit dem sich alles von einfachen statischen Websites bis zu Web-Apps für Echtzeit-Zusammenarbeit erstellen lässt; der Einstieg gelingt durch das Hinzufügen eines einzigen Script-Tags zu HTML
  • Es verfolgt einen Hypermedia-First-Ansatz, der HTML erweitert, damit sich interaktive UIs mit Backend-Zentrum erstellen lassen
  • Ähnlich wie htmx bietet es Backend-Reaktivität und unterstützt zugleich Frontend-Reaktivität wie Alpine.js; es funktioniert ohne npm-Pakete oder Abhängigkeiten
  • Im Frontend wird reaktives Verhalten über standardisierte data-*-Attribute umgesetzt, während im Backend per Ereignissen DOM-Änderungen und Statusänderungen ausgeführt werden
  • Mit Echtzeit-Updates auf Basis von SSE (Server-Sent Events) und SDKs für verschiedene Sprachen zielt es darauf ab, die entwicklung backend-gesteuerter reaktiver Web-Apps zu vereinfachen

Überblick über Datastar

  • Datastar ist ein Hypermedia-basiertes Framework zur Erweiterung von HTML, das so aufgebaut ist, dass sich interaktive Web-Apps in Echtzeit umsetzen lassen, indem das Backend das DOM direkt steuert
  • Auf Browser-Seite werden alle Funktionen aktiviert, indem lediglich ein 10,7-KB-Script geladen wird; Build-Tools oder die Installation eines Frameworks sind nicht nötig
  • Es übernimmt die Prinzipien von Hypermedia Systems, bei denen der Server den Zustand der UI vorgibt und der Client diesen reaktiv widerspiegelt
  • Durch die Verarbeitung von Datenaktualisierungen, Statusänderungen und DOM-Patching über Backend-Ereignisse wird die Frontend-Logik minimiert

Installation

  • Der einfachste Weg ist, das Script über ein CDN wie folgt einzubinden
  • Alternativ kann die Datei direkt heruntergeladen oder mit dem Datastar bundler ein eigenes Bundle erzeugt werden
  • Eine npm-Installation oder die Einrichtung einer Node-Umgebung ist überhaupt nicht erforderlich

data-*-Attribute und Reaktivität

  • Der Kern besteht darin, Verhalten deklarativ über die data-*-Attribute von HTML zu definieren
    • Beispiel: data-on-click="alert('Hello!')"
  • Das Attribut data-on legt einen Datastar-Ausdruck fest, der beim Auftreten eines bestimmten Ereignisses ausgeführt wird; dabei kann auch normales JavaScript verwendet werden
  • Eine spezielle VSCode-Erweiterung und ein IntelliJ-Plugin bieten Autovervollständigung und Syntaxunterstützung

Backend-gesteuertes DOM-Patching

  • Datastar arbeitet so, dass der Server das Frontend steuert
    • Sendet der Server HTML-Fragmente, fügt Datastar diese mit einer Morphing-Strategie in das DOM ein
    • Morphing aktualisiert nur die geänderten Teile, erhält den Zustand und verbessert die Performance
  • Beispiel: 
    <button data-on-click="@get('/endpoint')">Open the pod bay doors, HAL.</button>  
<div id="hal"></div>
    Wenn der Server ein HTML-Fragment zurückgibt, ersetzt Datastar das Element id="hal" automatisch

Streaming auf Basis von Server-Sent Events (SSE)

  • Der Server kann das Ereignis datastar-patch-elements senden, um das DOM in Echtzeit zu aktualisieren

  • Das folgende Beispiel gibt HALs Zeile aus und setzt sie nach 1 Sekunde wieder zurück

    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>

  • Zur Unterstützung stellt Datastar SDKs für verschiedene Sprachen bereit:

    • Clojure, C#, Go, Java, Kotlin, PHP, Python, Ruby, Rust, Node.js
    • Jedes SDK sendet DOM-Patching-Ereignisse über Klassen wie PatchElements oder ServerSentEventGenerator

Datastar Inspector und Werkzeuge

  • Zusätzlich zu den Entwicklerwerkzeugen des Browsers lassen sich SSE-Ereignisse mit dem Datastar Inspector visuell prüfen
  • Neben der offiziellen Dokumentation gibt es umfangreiche Materialien wie ein KI-generiertes DeepWiki, Code-Beispiele für LLMs und eine einseitige Dokumentation

Fazit

  • Datastar ist ein moderner Ansatz, der die Entwicklung HTML-zentrierter Hypermedia-Anwendungen vereinfacht
  • Es ist leichter als bestehende SPA-Frameworks und bietet eine ausgewogene reaktive Entwicklungserfahrung für Backend und Frontend
  • Es eignet sich für Projekte, die Echtzeit-Streaming, serverzentrierte UI-Steuerung und abhängigkeitsfreie Bereitstellung benötigen

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-10-12
Hacker-News-Kommentare

  • Das Datastar-Team sind großartige Leute mit klaren Überzeugungen und einer klaren Philosophie, die sich auch für Einsteiger großzügig Zeit nehmen. In der Kontroverse um die Pro-Version geht das etwas unter, aber das ist ganz klar keine Monetarisierungsstrategie, und das Unternehmen ist als Non-Profit registriert. Nur Funktionen, die lediglich eine kleine Minderheit braucht, wurden in Pro ausgelagert. Gerade weil vor allem diese kleine Gruppe mit genau diesen Anforderungen Anfragen stellt, steigt der Support-Aufwand stark an; so lässt er sich effizient steuern. Eigentlich ist das ein innovativer und fairer Ansatz, der (a) signalisiert, dass man bei solchen „Problemfunktionen“ vorsichtig sein sollte, (b) die Nutzer, die am meisten Support benötigen oder besonders viel Wert aus Datastar ziehen, einen kleinen Beitrag zahlen lässt, und (c) dem Team mehr Zeit für die gesamte Community verschafft, was insgesamt positiv ist.

    • Wenn Funktionen wie data-animate, data-on-resize oder data-scroll-into-view „Problemfunktionen“ sein sollen, dann sind sie nicht richtig entworfen. Ich glaube auch nicht, dass nur eine kleine Minderheit solche Funktionen braucht. Dass sie das, was sie wollen, kostenpflichtig machen, ist für mich okay, aber dafür muss man nicht noch Ausreden konstruieren.

    • Ich frage mich, ob eine Copy-to-Clipboard-Funktion wirklich so viel Support-Aufwand verursacht. Wenn Datastar auf diesem Niveau tatsächlich so schwach ist, dass selbst einfache Funktionen nur mit viel Support zuverlässig laufen, fällt es mir schwer, dem zuzustimmen.

  • Wer denkt, Datastar reiche für Echtzeit/Collaboration/Multiplayer nicht aus oder man brauche zwingend Pro-Funktionen, sollte sich diese drei Demos ansehen, die auf einem 5-Dollar-VPS laufen und es auch ohne Pro-Funktionen auf die HN-Startseite geschafft haben. Dann sieht man, was für bemerkenswerte Engineering-Arbeit Datastar ist.

  • Hinweis auf laufende verwandte HN-Diskussionsthreads:

  • Ich verstehe nicht ganz, warum die Community so feindselig reagiert. Datastar ist größtenteils Open Source, läuft mit jeder Sprache und ist auch als Projekt interessant, weil es darüber nachdenkt, wie sich die Entwicklung finanzieren lässt. Ich finde es völlig legitim, das eigene Projekt auf die eigene Art voranzutreiben. Ich will auch ein bisschen mit Go darin herumhacken, und danke für die Arbeit. Ich habe nur einen Punkt als Feedback: In meinem Land sind 299 Dollar eine enorme Summe, und einige Pro-Funktionen könnten trotzdem notwendig sein, daher ist der Preis zu belastend. Ich würde mir ein dynamisches, länderspezifisches Preismodell wie bei Steam oder vielleicht eine spendenartige Unterstützung wünschen. Dinge wie Animationen gibt es in SvelteKit kostenlos; es geht nicht darum, alles gratis haben zu wollen, sondern schlicht darum, es sich nicht leisten zu können. Für Unternehmen könnte man mehr verlangen und für Solo-Entwickler deutlich weniger. Ich habe bisher noch nie für eine Online-Community oder ein Projekt bezahlt, aber Datastar würde ich mit 5–10 Dollar gern unterstützen. Ich wünschte, der Solo-Tier würde preislich eher in der Größenordnung eines Switch-Spiels (silksong) liegen. Es ist schade, dass die Reaktion der Community auf ein wirklich tolles Projekt so ungewöhnlich kritisch ausfällt.

    • Das ist hier bislang für mich die einzige wirklich vernünftige Kritik. 299 Dollar sind für sehr viele Menschen tatsächlich nicht erreichbar. Andererseits könnte das im Vergleich zu dem Wert, den die Entwickler liefern, während sie in Ländern mit hohen Lebenshaltungskosten leben, auch ein kleiner Betrag sein. Ein länderspezifisches Preissystem zu wünschen, ist eine gute Idee, aber die Umsetzung ist schwierig, und der reale Nutzen könnte gering sein. Die kostenlosen Open-Source-Funktionen bieten bereits über 95 % des Werts und der Funktionalität, daher sollten die meisten, die keine Pro-Lizenz wirklich brauchen, einfach frei damit arbeiten, lernen oder Nutzen daraus ziehen.

    • Meine Kritik setzt an folgenden Punkten an:

      • Auf der Homepage gibt es überhaupt keinen Hinweis auf Pro; man erfährt es erst beim Stöbern in der Dokumentation. Das wirkt wie ein Lockmittel.
      • Pro bündelt nicht nur Support oder Beispiele, sondern echte Funktionen.
      • Wenn man von Pro-Funktionen abhängt, bindet man sich an Datastar und die Wartungshoheit liegt beim Anbieter.
      • Ohne Pro funktioniert die Site unter Umständen gar nicht, wodurch Vendor Lock-in ein noch größeres Problem wird.
      • Es gibt keine Demo-Beispiele, in denen man ausprobieren kann, was man bei Pro eigentlich kauft, so wie man es etwa bei Alpine.js oder React Flow Pro direkt im Browser testen kann.
      • Selbst wenn man den Quellcode erhält, kann man Verbesserungen nicht zurückteilen.
      • Es geht nicht um den Preis, sondern um Struktur und Wert; für manche ist es billig, für andere teuer.
      • Beispiele für keine schlechten Pro-Modelle: Alpine.js Pro, React Flow Pro

    • Auch kleine Unternehmen müssen ihren Support selbst leisten; in Ländern mit hohen Lebenshaltungskosten reicht man mit 5 Dollar nicht einmal für ein einzelnes Support-Ticket.

  • Ich entwickle seit einigen Monaten ein Frontend auf Basis von Go und Templ mit Datastar. Die @actions-Funktion und die Art, wie die Seite abhängig von der Antwort aktualisiert wird, gefallen mir sehr. Nur über die Signals-Funktion grüble ich persönlich noch. Für einzelne Felder oder Dropdowns ist sie okay, aber mein Backend hat eine Kubernetes-artige API, und wenn ich JSON-Ressourcen in Signals speichern will, passt das schlecht dazu, wie Datastar die Struktur in Sub-Signals zerlegt. Gerade Strukturen wie bei Kubernetes-Labels, bei denen Keys ein Hostname-Präfix haben, lassen sich überhaupt nicht vernünftig behandeln, und die Signals geraten durcheinander. Data Binding mit einfachen Key-Pfaden funktioniert gut, aber bei Pfaden, die Indizes oder Hostname-Keys benötigen, klappt es nicht. Dazu kommen die Regeln, nach denen HTML-Attribute in JS automatisch umgewandelt werden (snake→camel usw.), sowie die Modifier-Verarbeitung, die oft fehleranfällig und komplex ist. Trotzdem gefällt mir, dass HTMX-/Alpine-Funktionen in einem einzigen Hypermedia-Ansatz zusammengeführt werden. Ich finde auch gut, dass man dadurch dem NodeJS-Ökosystem ausweichen kann. In der RC-Phase hat sich das Wire Format einmal geändert; weil ich Fiber verwende und es ohne Go-SDK direkt implementiert habe, war das Update mühsam. Trotzdem halte ich die Formatänderung für eine gute Änderung. Das Team bewegt sich in eine gute Richtung, und ich hoffe, dass es sich weiter gut entwickelt.

  • Die Idee von Datastar wirkt auf mich sehr stark, und ich hatte auch schon über einen Einsatz nachgedacht. Meine Sorge ist nur, dass Einschränkungen in der Open-Source-Version, damit sie nicht mit Pro konkurriert, ein schneller Weg zu einem Hard Fork sein könnten. Ein großes Ökosystem gibt es ja auch nicht gerade, also sehe ich genug Gründe zum Wechseln.
    [edit: Ein Open-Core-Modell, bei dem einige Plugins geschlossen bleiben, kann durchaus sehr vernünftig sein, und selbst wenn nicht, gibt es viele Alternativen. Ich wünsche sowohl den Datastar-Entwicklern als auch den Nutzern Erfolg.]

    • Wenn du dir Sorgen wegen eines Hard Fork machst, dann wäre es für alle hilfreich, die Plugins aus der Zeit vor Pro zu forken und an die aktuelle Datastar-Pro-Version anzupassen. Das sind kleine Codeschnipsel von vielleicht 50 Zeilen, also wirklich sehr einfach.

    • Von „Einschränkungen“ zu sprechen ist überzogen. Die nur in Pro enthaltenen Attribute/Events sind wenige und keine Kernfunktionen. Im Grunde lässt sich das meiste mit ein wenig JS ersetzen, das man vom Server sendet. Eine konkrete Liste gibt es hier: https://data-star.dev/reference/datastar_pro

    • Ich würde einen Fork wirklich begrüßen. Hoffentlich macht das jemand.

  • Vielleicht liegt es daran, dass ich zu sehr an das React-Ökosystem gewöhnt bin, aber sobald Dinge eine gewisse Komplexität überschreiten, erscheint mir dieser Ansatz logisch deutlich schwieriger. Wenn ich das nicht falsch verstanden habe, ist Datastar ein Backend-Frontend-Muster, bei dem das Backend HTML zurückliefert, und aus früherer Erfahrung weiß ich: So möchte ich wirklich nicht noch einmal arbeiten. Vor allem bei Nutzern mit langsamer Verbindung (es gibt immer noch viele mit DSL, alten Satellitenverbindungen, 2G usw.) wird die wahrgenommene Performance stark leiden, weil sie statt kleiner JSON-Mengen mehrfach große HTML-Antworten bekommen.

    • Nach meiner Erfahrung mit React-Apps auf 2G/3G laden diese oft überhaupt nicht, während HTML-Inhalte bei den meisten Fällen innerhalb von 1–2 Sekunden sichtbar sind. Ingenieure bauen sich oft willkürlich wieder eigene Timeouts ein; den Fortschritt messe ich über Sockets, aber in der App selbst fehlt dieses Gefühl. Man sollte nicht zwanghaft versuchen, alles „snappy“ wirken zu lassen.

    • Dieses Muster „das Backend liefert HTML zurück“ war schon in der Zeit der 56k-Modems üblich, und ich erinnere mich noch daran, wie wir damals Layouts mit dutzenden verschachtelten table-Tags gebaut haben.

    • Frontend ist ein sehr breites Feld. Für persönliche Blogs oder Shops mit viel statischem Inhalt, schnellen Ladezeiten und wenig Interaktion sind Werkzeuge aus der htmx-Familie gut geeignet. Wenn man aber Apps auf dem Niveau von Figma oder Discord bauen will, reicht dieser Ansatz nicht aus. Wer es bis ins Extreme treibt, für den ist das DOM nur ein Gefängnis, und zufrieden ist man erst mit einer Kombination aus Canvas und GPU-Berechnung.

    • Für vollständig offlinefähige Anwendungen führt natürlich kaum ein Weg an einem anderen Ansatz vorbei. Aber die meisten Sites brauchen keinen dauerhaft persistierten Zustand; Seiten-Caching oder Event-Zustand reicht oft schon aus. Wenn man das Datastar JS SDK in einem Service Worker laufen lässt und nur den notwendigen Zustand mit Browser-Storage synchronisiert, kann das sogar die Rolle des Backends übernehmen. Selbst bei langsamer Verbindung erreicht man mit starker Kompression auf dem SSE-Stream oft über 90 % Kompressionsrate, auch wenn viele Informationen redundant übertragen werden. Langsames Internet geht meist auch mit langsamen Geräten einher, daher ist Datastar deutlich leichter als schwere Dinge wie React oder CSS-in-JS, und funktional verliert man dabei fast nichts, während alles sehr viel einfacher wird.

  • Das ist kein besonders neues Muster. In der Übergangszeit von DHTML zu XHR hat man diesen Ansatz schon einmal durchlaufen, und wegen aller möglichen Trade-offs wurde er fast komplett aufgegeben. Auch neue Techniken wie DOM-Patching bringen am Ende dieselben Probleme mit sich: enge Kopplung, Instabilität, große Datenmengen, Latenzprobleme. Datastar ist damit eher eine Lösung für kleine Firmen, die Entwicklungskosten senken wollen, als ein Durchbruch zu neuen technischen Grenzen. Es ist nicht schlecht, aber es fühlt sich an, als würde sich die Geschichte wiederholen.

    • Als Datastar-Autor: Dass daran nichts neu ist, ist sogar Absicht. Ich vermisse die gute alte Zeit, als jQuery nur leicht in Seiten eingegriffen hat, bevor SPAs angefangen haben, alles ins Frontend zu ziehen und dabei die grundlegende Wahrheit verloren ging, dass das Backend den Zustand hält. Ich will keine Revolution, sondern eine Rückkehr zur Normalität.

    • Irgendwie frage ich mich, ob Astro dieses Problem nicht bereits gelöst hat.

  • Das Video (der Film) unten auf der Seite ist so gut, dass ich es am liebsten im nächsten Projekt einsetzen würde. Besonders der Teil mit „The planet uncomplicanus“ ist mir im Gedächtnis geblieben.

  • Mir gefällt auch, was https://www.zjax.dev/ erreicht hat.