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