[zoezoezoezoe]

idk. I'm just extremely not sold on the idea of having practically any interaction going over the wire unless absolutely necessary. Keeping everything in the browser for as long as is physically possible is what improves responsiveness, a single page application, once loaded, is not susceptible to spotty connections, dropping packets, a slow connection, whatever, like html-over-the-wire is.

I have been extremely bearish on html-over-the-wire solutions from the minute I saw and understood what HTMX was trying to achieve. In my eyes, the only way to truly achieve what I, and users, expect in a web page is with a SPA. I understand the hesitation to use heavier SPAs, but my hesitation to fetching html from the server after the page load to update the page is much larger. But I also do understand how html-over-the-wire provides a good middle ground between web 1.0 apps where basically every interaction reloaded the entire page, and web 2.0 apps that feel closer to an actual application rather than a website.

[yawaramin]

But surely even in a SPA you have to eventually send a request and get a response? Like you're not going to suggest that eg in an online store webapp the user would click 'add to cart' and you wouldn't send a request to add the item to the cart and wait for and render the response?

Hypermedia libraries like htmx etc. are just doing these interactions, the ones that need a server request-response cycle. The difference is they get the response as already-rendered HTML, so they don't need to do anything further, just swap it in to the existing page. It's super simple and very efficient. And usually results in fewer AJAX calls which also are much more minimal and don't include any redundant data.