[csande17]

Basically, the HTMX code says: "when this span is clicked, fetch /rebuild/status-button, extract the #rebuild-bundle-status-button element from the returned HTML, and replace the existing #rebuild-bundle-status-button element with it".

The Datastar code instead says: "when this span is clicked, fetch /rebuild/status-button and do whatever it says". Then, it's /rebuild/status-button's responsibility to provide the "swap the existing #rebuild-bundle-status-button element with this new one" instruction.

If /rebuild/status-button returns a bunch of elements with IDs, Datastar implicitly interprets that as a bunch of "swap the existing element with this new one" instructions.

This makes the resulting code look a bit simpler since you don't need to explicitly specify the "target", "select", or "swap" parts. You just need to put IDs on the elements and Datastar's default behavior does what you want (in this case).

[lunar_mycroft]

Note that for this example you can get the same behavior (assuming the endpoint hit isn't using using SSE, which IMO Datastar over emphasizes) in HTMX via a combination of formatting your response body correctly and the response headers. It isn't the way things are typically done in HTMX for Locality of Behavior reasons, not because it's impossible.

[sudodevnull]

in Datastar the locality of behavior is in you backend state... datastar.Patch(renderComponent(db.NextRow)) imho, a single line is the ultimate LOB pattern. idk, ngmi

[brokegrammer]

I see, so the rendering logic is performed mostly on the back-end when using Datastar. It makes sense now, thanks.

[nchmy]

This is just SSR html/hypermedia in general - the way the web was designed and worked for a long time. This site is like that too!

HTMX's html attributes are similarly defined in the backend. The difference with datastar is which attributes and how they work