Warum ich von HTMX zu Datastar gewechselt bin

 (everydaysuperpowers.dev)
10 Punkte von GN⁺ 2025-10-11 | 2 Kommentare | Auf WhatsApp teilen
  • Mit HTMX ließ sich der Codeumfang zwar um etwa 70 % reduzieren, zugleich traten jedoch Synchronisierungsprobleme zwischen UIs sowie eine zunehmende Komplexität beim Frontend-Statusmanagement auf
  • Nach der Einführung von Datastar wurde es bei der Entwicklung von Echtzeit-Multiuser-Anwendungen möglich, ohne WebSockets mit schlankem Code zu arbeiten und die Wartung zu erleichtern
  • Während HTMX die Anwendungslogik auf HTML-Attribute verteilt, erhöht Datastar mit einem servergesteuerten Update-Modell die Konsistenz und Wartbarkeit der Logik
  • Die Datastar-API kommt mit weniger Attributen aus, was die Lesbarkeit und Produktivität des Codes verbessert
  • Datastar nutzt webnative Technologien wie Server-Sent Events (SSE), Web Components und CSS View Transitions aktiv, um Echtzeit-Zusammenarbeit und wiederverwendbare Komponentenstrukturen zu ermöglichen

Einführung und Motivation

Probleme, die den Wechsel auslösten

  • Bei der Vorbereitung eines Vortrags für die FlaskCon 2025 wurde versucht, die UI mit einer Kombination aus HTMX und AlpineJS zu synchronisieren, dabei stieß man jedoch auf Synchronisierungsprobleme
    • Die beiden Bibliotheken sind getrennte Werkzeuge verschiedener Entwickler und können nicht direkt miteinander kommunizieren, sodass die Integrationsarbeit vom Entwickler selbst übernommen werden muss
    • Beim Initialisieren von Komponenten zu unterschiedlichen Zeitpunkten und beim Abstimmen von Events war deutlich mehr Code und Debugging-Zeit nötig als erwartet
  • Auffällig war, dass Datastar die Funktionen beider Bibliotheken vereint und dabei weniger als 11 KB groß ist, weshalb es ausprobiert wurde
    • Das ist insbesondere für die Ladeperformance auf Mobilgeräten vorteilhaft

Das bessere API-Design von Datastar

  • Die API von Datastar wirkt im Vergleich zu HTMX deutlich leichtergewichtig, und es sind weniger zusätzliche Attribute nötig, um das gewünschte Ergebnis zu erzielen
  • HTMX benötigt bei den meisten Interaktionen mehrere Attribute
    • URL-Definition, Ziel-Element und Art der Antwortverarbeitung werden jeweils über eigene Attribute konfiguriert
    • In der Regel werden 2–3 Attribute pro Fall verwendet, und manchmal muss man entlang einer Vererbungskette nachverfolgen, wie ein Attribut funktioniert
    <a hx-target="#rebuild-bundle-status-button"  
   hx-select="#rebuild-bundle-status-button"  
   hx-swap="outerHTML"  
   hx-trigger="click"  
   hx-get="/rebuild/status-button"></a>
  • Mit Datastar lässt sich dieselbe Funktion meist mit nur einem einzigen Attribut umsetzen 
    <a data-on-click="@get('/rebuild/status-button')"></a>
    • Auch Monate später lässt sich beim erneuten Lesen des Codes leicht nachvollziehen, wie er funktioniert

Unterschiede im Funktionsprinzip

  • HTMX ist eine Frontend-Bibliothek, die HTML erweitern will, während Datastar eine servergesteuerte Bibliothek ist, die auf den Aufbau leistungsfähiger, webnativer Echtzeit-Update-Anwendungen abzielt
  • HTMX definiert Verhalten über Attribute an dem Element, das die Anfrage auslöst. Selbst wenn weit entfernte Elemente auf der Seite aktualisiert werden, verteilt sich die Logik dadurch über mehrere Ebenen
  • Bei Datastar entscheidet der Server, was geändert wird, sodass die gesamte Update-Logik an einer Stelle gebündelt ist

  • HTMX-Beispiel

    <div>  
  <div id="alert"></div>  
    <button hx-get="/info"   
            hx-select="#info-details"   
            hx-swap="outerHTML"  
            hx-select-oob="#alert">  
        Get Info!  
    </button>  
</div>
    • Beim Klick auf die Schaltfläche wird eine GET-Anfrage an /info gesendet, der Button durch das Element mit der ID info-details aus der Antwort ersetzt und zugleich das Element mit der ID alert auf der Seite durch das gleichnamige Element aus der Antwort ausgetauscht
    • Das Button-Element muss zu viel wissen, und da es im Voraus wissen muss, was der Server zurückliefern wird, wird das HTMX-Prinzip der „locality of behavior“ geschwächt

  • Verbesserter Ansatz von Datastar

    <div>  
    <div id="alert"></div>  
    <button id="info-details"  
    data-on-click="@get('/info')">  
        Get Info!  
    </button>  
</div>
    • Der Server gibt einen HTML-String mit zwei Root-Elementen zurück, die dieselben IDs tragen 
      <p id="info-details">These are the details you are looking for…</p>  
<div id="alert">Alert! This is a test.</div>
    • Eine einfache und performante Option

Auf Komponentenebene denken

  • Ein besserer Ansatz besteht darin, HTML als Komponenten zu behandeln
  • Dabei wird das Wesen der betreffenden Komponente betrachtet
    • Wie der Nutzer zusätzliche Informationen zu einem bestimmten Element erhält
    • Klickt der Nutzer auf den Button, werden entweder Informationen angezeigt oder bei fehlenden Daten ein Fehler gerendert; in beiden Fällen geht die Komponente in einen statischen Zustand über

  • Komponenten nach Zustand trennen

    • Platzhalterzustand: 
      <!-- info-component-placeholder.html -->  
<div id="info-component">  
    <button data-on-click="@get('/product/{{product.id}}/info')">  
        Get Info!  
    </button>  
</div>
    • Zustand zur Anzeige der Informationen: 
      <!-- info-component-get.html -->  
<div id="info-component">  
    {% if alert %}<div id="alert">{{ alert }}</div>{% endif %}  
    <p>{{product.additional_information}}</p>  
</div>
    • Sobald der Server das HTML rendert, aktualisiert Datastar die Seite automatisch
    • Denken auf Komponentenebene verhindert, dass man in ungültige Zustände gerät oder den Nutzerzustand verliert

Mehrere Komponenten gleichzeitig aktualisieren

  • Ein besonders eindrucksvoller Punkt in David Guillots Vortrag war, dass beim Aktualisieren der Anzahl bevorzugter Elemente nicht nur die geänderte Komponente, sondern auch ein weit entferntes Zählelement mit aktualisiert wurde
    • In HTMX würde dafür ein JavaScript-Event ausgelöst, das wiederum eine GET-Anfrage an die entfernte Komponente triggert
  • Mit Datastar lassen sich mehrere Komponenten sogar innerhalb einer synchronen Funktion gleichzeitig aktualisieren

  • Beispiel Warenkorb

    • Komponente zum Hinzufügen in den Warenkorb: 
      <form id="purchase-item"  
      data-on-submit="@post('/add-item', {contentType: 'form'})">"  
>  
  <input type=hidden name="cart-id" value="{{cart.id}}">  
  <input type=hidden name="item-id" value="{{item.id}}">  
  <fieldset>  
    <button data-on-click="$quantity -= 1">-</button>  
    <label>Quantity  
      <input name=quantity type=number data-bind-quantity value=1>  
    </label>  
    <button data-on-click="$quantity += 1">+</button>  
  </fieldset>  
  <button type=submit>Add to cart</button>  
  {% if msg %}  
    <p class=message>{{msg}}</p>  
  {% endif %}  
</form>
    • Komponente zur Anzeige der Warenkorbanzahl: 
      <div id="cart-count">  
    <svg viewBox="0 0 10 10" xmlns="http://www.w3.org/2000/svg">  
        <use href="#shoppingCart">  
    </svg>  
    {{count}}  
</div>
    • In Django werden beide Komponenten mit derselben Anfrage aktualisiert: 
      from datastar_py.consts import ElementPatchMode  
from datastar_py.django import (  
    DatastarResponse,  
    ServerSentEventGenerator as SSE,  
)  

def add_item(request):  
    # wichtige Statusaktualisierungen ausgelassen  
    return DatastarResponse([  
        SSE.patch_elements(  
            render_to_string('purchase-item.html', context=dict(cart=cart, item=item, msg='Item added!'))  
        ),  
        SSE.patch_elements(  
            render_to_string('cart-count.html', context=dict(count=item_count))  
        ),  
    ])

Webnative Philosophie

  • Über die Datastar-Discord-Community wurde klar, dass Datastar nicht nur ein Hilfsskript ist, sondern eine Philosophie zum Bau von Apps mit den grundlegenden Primitiven des Webs
  • Während HTMX darauf abzielt, die HTML-Spezifikation weiterzuentwickeln, interessiert sich Datastar stärker dafür, die Nutzung webnativer Funktionen zu fördern
    • CSS view transitions
    • Server-Sent Events
    • Web Components usw.
  • Ein großer Erfolg war das Refactoring komplexer AlpineJS-Komponenten hin zu einfachen Web Components, die sich an mehreren Stellen wiederverwenden lassen
  • Auch ohne Werkzeuge wie React ist dies ein hervorragendes Muster, um über benutzerdefinierte HTML-Elemente hohe locality of behavior und Wiederverwendbarkeit zu erreichen

Echtzeit-Updates für Multiuser-Apps

  • Anwendungen, in denen Zusammenarbeit eine Funktion erster Klasse ist, heben sich von anderen Apps ab, und Datastar adressiert genau diese Aufgabe
  • Die meisten HTMX-Entwickler holen Informationen per Polling vom Server oder schreiben eigenen WebSocket-Code, was die Komplexität erhöht
  • Datastar verwendet mit Server-Sent Events (SSE) eine einfache Webtechnologie, mit der der Server Updates an verbundene Clients pushen kann
    • Wenn ein Nutzer einen Kommentar hinzufügt oder sich ein Zustand ändert, aktualisiert der Server den Browser sofort, bei minimalem Zusatzcode
    • So lassen sich Echtzeit-Dashboards, Admin-Panels und Kollaborationstools auch ohne eigenes JavaScript erstellen
  • Wird die Client-Verbindung unterbrochen, versucht der Browser automatisch die Wiederverbindung, ohne dass zusätzlicher Code nötig ist
    • Dem Server kann dabei auch das zuletzt empfangene Event mitgeteilt werden

Übermäßige Komplexität vermeiden

  • Die Datastar-Discord-Community half dabei, Datastars Vision für den Bau von Web-Apps zu verstehen
    • Push-basierte UI-Updates
    • Weniger Komplexität
    • Nutzung von Werkzeugen wie Web Components zur Behandlung lokal komplexer Situationen
  • Die Community hilft neuen Nutzern auch zu erkennen, wenn sie an ein Problem unnötig kompliziert herangehen

Wichtige Tipps

  • Scheue dich nicht davor, ganze Komponenten erneut zu rendern und zu übertragen
    • Das ist einfacher und hat kaum Auswirkungen auf die Performance
    • Es kann sogar zu besserer Kompression führen, und Browser parsen HTML-Strings sehr schnell
  • Der Server ist die Quelle der Wahrheit und leistungsfähiger als der Browser
    • Der Server sollte den Großteil des Status verwalten, und reaktive Signale werden womöglich seltener benötigt als gedacht
  • Web Components eignen sich hervorragend dazu, Logik in benutzerdefinierten Elementen mit hoher locality of behavior zu kapseln
    • Das Sternenfeld im Header der Datastar-Website ist ein gutes Beispiel
    • Das Element <ds-starfield> kapselt den gesamten Code für die Sternenfeld-Animation und stellt drei Attribute bereit, um den internen Zustand zu verändern
    • Datastar steuert diese Attribute, wenn sich ein Range-Input ändert oder wenn sich die Maus über dem Element bewegt

Möglichkeiten jenseits bisheriger Grenzen

  • Am spannendsten ist das Potenzial dessen, was Datastar möglich macht
  • Die Community erstellt regelmäßig Projekte, die weit über die Grenzen hinausgehen, die Entwickler mit anderen Werkzeugen typischerweise erleben

Bemerkenswerte Beispiele

  • Das Datenbank-Monitoring-Demo auf der Beispielseite
    • Nutzt Hypermedia und verbessert Geschwindigkeit und Speicherverbrauch eines auf einer JavaScript-Konferenz vorgestellten Demos deutlich
  • Anders Murphys 1 Milliarde Kontrollkästchen
    • Nachdem ein Experiment mit 1 Million Kontrollkästchen die Serverkapazität überschritt, wurden mit Datastar 1 Milliarde auf einem günstigen Server umgesetzt
  • Eine Web-App, die die Daten aller Radarstationen in den USA anzeigt
    • Ändert sich das Signal eines Radars, ändert sich der entsprechende Punkt in der UI innerhalb von 100 Millisekunden
    • Es werden mehr als 800.000 Punkte pro Sekunde aktualisiert, und Nutzer können bis zu eine Stunde zurück scrubben, bei einer Latenz von unter 700 Millisekunden
    • Dass so etwas als Hypermedia-App möglich ist, zeigt, was Datastar ermöglichen kann

Aktuelle Nutzungserfahrung

  • Der Autor befindet sich weiterhin in einer Erkundungsphase mit Datastar und setzt damit die AJAX-artige UI-Aktualisierung klassischer HTMX-Funktionen schnell und einfach um
  • Gleichzeitig werden verschiedene Muster gelernt und ausprobiert, um mit Datastar noch mehr zu erreichen
  • Seit Jahrzehnten besteht Interesse daran, wie Echtzeit-Updates die Nutzererfahrung verbessern können, und besonders positiv ist, dass Datastar push-basierte Updates auch in synchronem Code ermöglicht
  • Schon beim Einstieg in HTMX war die Freude groß, doch seit dem Wechsel zu Datastar hat der Autor nicht das Gefühl, etwas verloren zu haben, sondern vielmehr sehr viel mehr gewonnen zu haben
  • Wer mit HTMX Freude hatte, wird mit Datastar vermutlich denselben Sprung noch einmal erleben — als würde man neu entdecken, was das Web eigentlich leisten sollte

Verwandte Beiträge

2 Kommentare

 
GN⁺ 2025-10-11
Hacker-News-Kommentare
  • Ich schätze es, dass Chris seine Komfortzone verlässt, sich einer Herausforderung stellt und diese Erfahrung mit uns teilt. Ich bin möglicherweise etwas voreingenommen, weil ich seit vier Jahren Web-Apps mit htmx baue, aber ich denke, hier zeigt sich der zentrale architektonische Unterschied zwischen Datastar und htmx: htmx ist HTML-gesteuert, Datastar servergesteuert. Dass die clientseitige API einfacher ist, stimmt zwar, aber das liegt daran, dass die serverseitige Logik komplexer wird. Wenn ein HTML-Element zum Beispiel keine Information darüber hat, wo ein vom Server zurückgegebenes Fragment eingefügt werden soll, dann muss diese Information serverseitig festgehalten werden — die Komplexität existiert also zwangsläufig auf der einen oder anderen Seite. Die Wahl der Architektur scheint mir letztlich eine Geschmacksfrage zu sein. Die Argumentation mit den „less attributes“ im Beispiel ist nicht ganz fair, weil dort auch Attribute aufgeführt werden, die in htmx optional sind; lässt man etwa hx-trigger="click" weg, sind schon 20 % der Attribute verschwunden. Und wenn man semantisch zugänglicheres HTML schreiben würde, also zum Beispiel <span> durch <button> ersetzt, wirkte das Ganze glaubwürdiger. Letztlich scheint die Stärke von Datastar darin zu liegen, dass Funktionen von Alpine oder Stimulus direkt eingebaut sind, und das ist wirklich beeindruckend
    • Ich denke, mit Datastar wird die Komplexität deutlich reduziert, weil man zur Echtzeit-Aktualisierung anderer Bereiche einer Seite kein separates Eventing implementieren muss, sondern alles auf einmal herunterladen und aktualisieren kann. Natürlich kann je nach Fall ein ereignisbasiertes Vorgehen oder ein späteres Nachladen sinnvoller sein
    • Die Aussage „wie Alpine oder Stimulus, aber direkt in HTMX eingebaut“ bringt mich dazu, über HTMX für ein Privatprojekt nachzudenken. Ich frage mich, ob es Material gibt, das erklärt, warum man zusätzliche Bibliotheken wie AlpineJS oder Stimulus überhaupt braucht
    • Es wurde darüber gesprochen, dass der Server wissen muss, wo ein Fragment eingefügt werden soll, wenn diese Information im HTML-Element fehlt. Da frage ich mich, ob das Frontend in so einem Fall nicht leichter und schneller wäre — besonders wenn es sehr viele Elemente gibt
    • Diese Struktur erinnert etwas an das Seaside-Framework von Pharo. Als wir in unserer Firma B2B-Apps mit Pharo gebaut haben, wurde der UI-Zustand im Backend verwaltet, wodurch sehr viel zwischen Frontend und Backend hin- und herging. Für B2B, wo Echtzeit und Latenz nicht so kritisch sind, ist das okay, aber für stark skalierende B2C-Apps passt es nicht
  • Ich habe sowohl Datastar als auch HTMX direkt benutzt, und mir ist noch nicht klar, worin beim Bau einer App mit Datastar der große Unterschied liegen soll. Ich verwende FastAPI, HTMX, Alpine.js und SSE zusammen für Dinge wie Echtzeit-Loganzeige und Aktualisierung des Deployment-Status. Wenn ich mir Datastar-Beispiele ansehe, erkenne ich noch nicht, was daran einfacher sein soll als an diesem Aufbau. (Code dazu: devpush SSE partial). Web Components hatte ich früher bei der Entwicklung von Basecoat ebenfalls ausprobiert, bin aber aus verschiedenen Gründen wie Styling-Problemen und State-Management letztlich wieder zu klassischem HTML/CSS/JS zurückgekehrt. devpu.sh, basecoatui.com
    • Auch mit HTMX ist es im Hinblick auf funktionale Erweiterbarkeit oft einfacher, einfach die komplette Liste auf einmal zu aktualisieren, so wie bei Datastar. Statt den Status einzelner Deployments zu aktualisieren, ist ein Update der gesamten Liste viel simpler, weil man sich um Edge Cases wie Paginierung gar nicht erst kümmern muss und der Code dadurch deutlich schlanker wird
  • Falls jemand denkt, Datastar sei für Echtzeit/Kollaboration/Multiplayer unzureichend: Ich möchte drei Demos vorstellen, die auch ohne PRO-Features funktionieren und es sogar auf die HN-Startseite geschafft haben — auf einem 5-Dollar-VPS. Sie zeigen, wie gut Datastar gemacht ist: Checkboxes, Cells, Game of Life Example. Die Checkbox- und Cell-Beispiele haben ein dynamisches View-Rendering, sodass man ziemlich weit herauszoomen kann, und virtuelles Scrolling mit Backpressure ist ebenfalls vorhanden
    • Wenn ich die Code-Struktur richtig verstanden habe, wird offenbar gar nicht der von Datastar empfohlene Diff/Patch-Ansatz verwendet, sondern bei jedem Mal die ganze Seite neu gerendert. Ehrlich gesagt wirkt dieses mentale Modell viel einfacher als Beispiele, in denen der Server den Client-Zustand fein granular nachverfolgt, und gerade deshalb finde ich es attraktiv. Ich frage mich, ob sich auch gewöhnlich komplexe Apps auf diese Weise bauen lassen. Wenn Nutzer zwischen verschiedenen Seiten wechseln und dabei auch unterschiedliche Widget-Zustände verfolgt werden müssen, damit sofort neu gerendert werden kann, wäre ich dankbar für Hinweise auf Texte, die das erklären
    • Beim Checkboxes-/Cells-Beispiel wurde gesagt, dass man herauszoomen kann — wie genau funktioniert das? Und ich hätte es gut gefunden, wenn es eine Option wie data-replace-url gäbe, die die URL der aktuellen Ansicht automatisch auf die entsprechenden Koordinaten (x=123&y=456 usw.) aktualisiert
    • Durch die Erwähnung der PRO-Features habe ich erst erfahren, dass es sich um ein Open-Core-Modell handelt (ein Teil Open Source, der Rest kostenpflichtig, 299-Dollar-Lizenz). Für mich ist das ein Ausschlusskriterium
  • Ich habe vor Kurzem diesen Beitrag gelesen (htmx, datastar, greedy developer) und gehört, dass gute Kernfunktionen von Datastar in die Bezahlversion (Pro) verschoben wurden. Ich würde ein Framework finanziell unterstützen, egal ob Open Source oder kommerziell, aber so ein Präzedenzfall ist etwas besorgniserregend
    • Ich habe Datastar auch einige Monate lang verfolgt und auf den 1.0.0-Release gewartet, aber inzwischen ist meine Erwartung völlig verflogen. Ich bin schon zu oft auf Fälle hereingefallen, die „Open Source, aber eigentlich doch nicht“ waren, und habe deshalb kein Vertrauen mehr
    • Eigentlich habe ich bisher eher geschrieben, dass ich Datastar nicht besonders mag, aber diesmal möchte ich Datastar etwas verteidigen. Der Framework-Autor hat seinen Code unter MIT kostenlos veröffentlicht, also können die früher frei veröffentlichten Features weiterhin unter MIT genutzt werden. Wenn man nur genutzt und nicht beigetragen hat, ist es die eigene Entscheidung, auf älteren Versionen zu bleiben. Dass man ab jetzt auf ein Bezahlmodell umstellt, ist die Freiheit des Produktinhabers, und wenn nötig kann man es einfach forken
    • Ich habe die 299 Dollar für die PRO-Lizenz einmalig bezahlt, aber bisher noch keine PRO-Funktionen tatsächlich verwendet. Ich wollte einen Google-Sheets-Klon bauen, aber selbst das ließ sich auch ohne PRO ausreichend umsetzen. (siehe Cells-Demo)
    • Ich hatte bei Datastar öfter den Eindruck, dass dort nicht nur im HTMX-Discord ständig dafür geworben wird, wie großartig Datastar sei, sondern dass das teilweise schon etwas aggressiv wirkte. Auf reddit habe ich auch Kommentare gesehen, die sinngemäß sagten: „Wenn du alles hast, was du brauchst, benutze einfach für immer die Beta; Open Source schuldet niemandem etwas“
    • Als ich Datastar benutzt habe, musste ich sofort an den früheren Fall von Meteor.js denken. (Meteor.js HN-Diskussion)
  • Die Beispielcodes in diesem Beitrag sind für mich nicht gut nachvollziehbar. Zum Beispiel scheint dieses htmx-Beispiel <span hx-target="#rebuild-bundle-status-button" hx-select="#rebuild-bundle-status-button" hx-swap="outerHTML" hx-trigger="click" hx-get="/rebuild/status-button"></span> in so etwas wie diesen Datastar-Code umgewandelt zu werden: <span data-on-click="@get('/rebuild/status-button')"></span> Und andere Beispiele verwirren noch mehr. Ich verstehe also am Ende nicht, warum man überhaupt von htmx zu Datastar wechseln sollte
    • Im Kern bedeutet HTMX hier: „Wenn auf dieses span geklickt wird, hole HTML von /rebuild/status-button, extrahiere aus dem zurückgegebenen HTML das Element #rebuild-bundle-status-button und ersetze dann das bestehende Element.“ Bei Datastar heißt es dagegen eher: „Wenn auf das span geklickt wird, folge einfach den Anweisungen von /rebuild/status-button.“ Gibt der Server mehrere Elemente mit IDs zurück, erkennt Datastar diese automatisch und ersetzt alle entsprechenden Elemente. Man muss also target, select und swap nicht extra angeben; IDs reichen aus, damit es wie beabsichtigt funktioniert
    • Die Struktur von Datastar verlagert die Logik ins Backend. Es ist wie bei traditionellem HTML: Man stellt eine Anfrage, bekommt HTML zurück, und der Browser rendert es direkt — nur dass Datastar nach dem einmaligen Laden der Seite bei jeder Interaktion Anfragen ans Backend schickt und nur die Änderungen übernimmt, ähnlich wie bei einer PWA. Es ist die umgekehrte Struktur einer SPA (Single-Page-App), bei der das Frontend ohne viel Backend-Logik den gesamten Zustand verwaltet. Im Kern kehrt also dieselbe Frage der Aufteilung von Backend- und Frontend-Logik wieder, und Datastar ermöglicht es, die Logik auf den Server zu konzentrieren und trotzdem eine dynamische Oberfläche zu behalten
    • Allerdings frage ich mich, warum man überhaupt ein span als klickbares Element verwendet. Ein button oder Link wäre doch passender
  • Ironischerweise geht es in diesem Artikel um Hypermedia, aber ein Link zur offiziellen Datastar-Website fehlt. Hier ist sie: https://data-star.dev/
  • Einer der großen Vorteile von HTMX ist, dass der Client die vom Server zurückgegebenen Datenstrukturen nicht kennen muss. Wenn der Client aber einzelne Element-IDs oder deren Bedeutung kennen muss, scheint dieses Versprechen gebrochen zu werden. Andererseits wird in vielen realen Projekten OOB (Out of Band) verwendet, sodass eine perfekte Trennung der Struktur ohnehin etwas von der Realität entfernt ist. Es wäre schön, wenn es einen Weg gäbe, die Vorteile beider Welten zu vereinen
    • Im Grunde muss der Client gar nichts wissen. Der Client kann einfach eine Aktion auslösen, der Server liefert die komplette Seitenansicht zurück, und der Client rendert sofort alles neu. Das ähnelt dem Immediate-Mode-Modell aus Videospielen
  • Dass Datastar HTML auf diese Weise serverseitig patcht, scheint mir im Sinne der Separation of concerns nicht besonders gut zu sein, und je größer eine App wird, desto mühsamer dürfte es werden, ständig HTML-Teile vom Server aus einzuspeisen
    • Das heißt aber nicht, dass es besser wäre, wenn JS überall per Fragmenten HTML einfügt
    • Die Art, Endpunkte zu entwerfen, die HTML-Fragmente vom Server ausliefern, fühlt sich irgendwie unangenehm an
  • Datastar wirkt auf mich runder als htmx. Ich habe mit htmx einige Projekte erfolgreich umgesetzt, aber ich fand es immer schade, dass ich für die Event-Behandlung zusätzlichen JS-Glue-Code schreiben musste, oft mit AlpineJS oder Ähnlichem. Wenn Datastar sogar diesen Bedarf reduzieren kann, wäre das wirklich vielversprechend
    • Ich empfehle, auf der Datastar-Website den Essay „grugs around the fire“ zu lesen
  • Ich bin relativ spät auf den Hypermedia-Trend aufgesprungen. Zuerst habe ich Datastar benutzt, inzwischen bin ich aber zu HTMX gewechselt. Die Datastar-API ist zwar etwas besser, aber seit htmx 2.0 OOB-Updates (Out-Of-Band) unterstützt, gebe ich in den meisten Fällen htmx den Vorzug
    • Die Formulierung „spät bei Hypermedia“ ist bemerkenswert. Interessant ist, dass Ted Nelson diesen Begriff bereits 1965 geprägt hat und damals schrieb: „hyperfilm— a browsable or vari-sequenced movie— is only one of the possible hypermedia that require our attention“. Zum entsprechenden Paper
    • Was mich beim Umgang mit OOB-Elementen in HTMX stört: 1. Wenn etwas OOB ist, braucht man zwingend htmx-swap-oob="true"; ohne dieses Attribut funktioniert es anders als erwartet. 2. Umgekehrt wird htmx-swap-oob="true" ignoriert oder verhält sich falsch, wenn es nicht OOB ist. Dadurch muss der Server bei der Wiederverwendung derselben Komponente als OOB/Nicht-OOB jedes Mal ein isOob-Flag mitliefern, was ziemlich lästig ist
    • Mir gefällt die API von alpine-ajax besser. Man gibt einfach mehrere Targets an, und die jeweiligen Elemente werden konsistent ohne JS ersetzt. Das Signal-/State-Konzept von Datastar empfinde ich eher als zusätzliche Komplexität und daher nicht als besonders attraktiv