[the_gastropod]

Versus the overwhelmingly common SPA counterexample where any change in the UI means sending a request to the server, waiting for it return your json response, parsing that json response, building html out of that json response, and updating the dom.

[robertoandred]

You don't need to wait for a response if you're sending data, or reorganizing data, or doing something that doesn't rely on data.

[the_gastropod]

Yep. DOM manipulation can be done to server-rendered views to do that kind of thing, just fine. No SPA js framework required.

[robertoandred]

So now you've got two templates? How do you keep modifications in sync?

[ColonelPhantom]

Personally I would use htmx and roundtrips for all sorts of modification including data (such as reorganizing two rows in a table). But you'd also do that in an SPA, right? How do you prevent desyncs there? Also for e.g. sorting you'd need a server roundtrip anyway in the (likely) case where you use something like pagination or lazy loading.

For sending data, you would just have a reply that instructs HTMX to display a success message. On an SPA you'd have the same. With both, you can interact with the page while the data is being sent.

Of course, sometimes you want purely 'cosmetic' actions, such as an "add row" button that pops open some data entry fields. For something like that you should not use htmx itself, but instead basic vanilla JS or a simple library such as https://alpinejs.dev/ which complements htmx nicely for client-side stuff.

[robertoandred]

I mean modifications to the template itself. Design changes, copy changes, etc

[acdha]

I go with the core idea of progressive enhancement: your front end code can improve what the server sent it rather than completely replacing it - if your style changes don’t break the semantic meaning, you don’t need to change any of your front end code.

What I typically do is render the first bit of data on the server and have the client JS use that as a <template> for changes or new records. That ensures that anything done on the client always matches without you needing to code cosmetics in multiple places but also means your pages load seconds faster than a SPA because the first view is ready to go. When the user saves the entry, you can swap what you generated with the server response a few milliseconds later.