Hacker News Reader

Comment by amaury_bouchard | Hacker News Reader

Fair enough, it's clearly not the right tool for everyone. HTML-over-the-wire works well for server-rendered apps where the primary interaction is fetching and displaying content. For highly interactive UIs with complex client-side state, a proper SPA framework is the better choice. Different problems, different tools.

That said, the vast majority of websites are purely transactional: click a link, load a page; submit a form, load a page. For those, there's little reason to add a full frontend framework. HTML-over-the-wire can improve responsiveness without adding complexity.

View on HN

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.

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.

Reply on news.ycombinator.com