[brokegrammer]

I don't understand the examples in this post. For example, how does:

<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>

Turn into:

<span data-on-click="@get('/rebuild/status-button')"></span>

The other examples are even more confusing. In the end, I don't understand why the author switched from HTMX to Datastar.

[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

[gethly]

It is quite simple.

Datastar keeps the logic in the backend. Just like we used to do with basic html pages where you make a request, server returns html and your browser renders it.

With Datastar, you are essentially doing kind of PWA where you load the page once and then as you interact with it, it keeps making backend requests and render desired changes, instead of reloading the entire page. But yo uare getting back snippets of HTML so the browser does not have to do much except rendering itself.

This also means the state is back in the backend as well, unlike with SPA for example.

So again, Datastar goes back to the old request-response HTML model, which is perfectly fine, valid and tried, but it also allows you to have dynamic rendering, like you would have with JavaScript.

In other words, the front-end is purely visual and all the logic is delegated back to the backend server.

This essentially is all about thin client vs smart client where we constantly move between these paradigms where we move logic from backend to the frontend and then we swing back and move the logic from the frontend to the backend.

We started with thin clients as computers did not have sufficient computing power back in the day, so backend servers did most of the heavy lifting while the thin clients very little(essentially they just render the ready-made information). That changed over time and as computers got more capable, we moved more logic to the frontend and it allowed us to provide faster interaction as we no longer had to wait for the server to return response for every interaction. This is why there is so much JavaScript today, why we have SPAs and state on the client.

So Datastar essentially gives us a good alternative to choose whether we want to process more data on the backend or on the frontend, whilst also retaining the dynamic frontend and it is not just a basic request-response where every page has to re-render and where we have to wait for request to finish. We can do this in parallel and still have the impression if a "live" page.

[hollowturtle]

You explained nothing about how it actually works, seems an ai generated response

[gethly]

Thanks, brings me back to my youth when I was being accused of cheating or being a bot in Counter-Strike :)

If you still don't get it, Datastar is essentially like a server-side rendering in JS, for PWAs, but it allows you to use any language you want on the backend whilst having a micro library(datastar itself) on the frontend. Allowing you to decouple JS from frontend and backend whilst still having all the benefits of it.

[youngtaff]

Also why is it a span instead of a button or link?

[bwklein]

My guess is to demonstrate that any element can be interactive with D*, not just buttons or links.