[oefrha]

Totally depends on your latency to the server and server response time. Please don’t throw away two decades of client side advancements and do this for state changes that should be entirely local, people with higher latency will hate your guts. Use alpine or something like that if you don’t want to go full react/vue/svelte/solid/etc. It’s utterly terrifying that I now see this pattern evangelized every day.

As an aside, I hate websites/apps sending HTML fragments like it’s 2005 because it’s much harder to pull data or automate things that way. But that’s usually considered an upside for developers who want to combat scraping. In practice it’s hardly a road bump for devoted scrapers, and actually increases server load for the same amount of data pulled, but it’s still considered a win by many.

[allknowingfrog]

I've been following projects like Hotwire and HTMX for awhile now, and I haven't seen anyone argue that scraping is a major reason to adopt this approach. I also don't see a lot of opposition to the idea of incorporating something like alpine to add some UI niceness.

What you see as a "terrifying" disregard for "two decades of advancements", others see as a liberating departure from two decades of unnecessary bloat. It's healthy to have more than one strategy available for building web applications.

[meiraleal]

> others see as a liberating departure from two decades of unnecessary bloat

Is moving the bloat to a blackbox in the backend really a better approach? Why not just not create a bloated frontend?

[allknowingfrog]

Using htmx allows you to completely skip a layer of JSON serialization and parsing. It eliminates the complexity of maintaining a second, frontend application, as well as all of its build tools and dependencies. It even opens up the freedom to work exclusively in your preferred language. All of these are examples of removing elements, not just hiding them somewhere else.

[p_l]

Because it might be in fact easier and simpler to implement it on backend?

[meiraleal]

it might, it probably isn't. Unless you only have a hammer.

[p_l]

What is, and what isn't easier has a big honking "IT DEPENDS" attached.

And I have a strong suspicion for many the beloved hammer is big complex client-side JS framework.

[recursivedoubts]

the htmx/hypermedia approach doesn't perclude scripting for client-side interactions:

https://htmx.org/essays/hypermedia-friendly-scripting/

https://hypermedia.systems/client-side-scripting/

[oefrha]

It does not, and I was specifically talking about local state changes. I’ve seen it misused a fair bit, and these trivial examples that tend to be local in real applications don’t help guiding developers who are not keenly aware of the existence of poor connections.

Additionally, while not htmx, in the adjacent land of LiveView, client side scripting is a bitch. I built a complex application in LiveView two years ago and later regretted it. Hard to resolve client side state and server side state diverging with complex but local state changes, and complex local changes are made more difficult than good old imperative jQuery thanks to a managed DOM. It’s extremely tempting to render local state changes with an HTML patch from the server to avoid all the pain, but like I said, high latency users will hate my guts for it.

[pmarreck]

I guess you're not a LiveView fan then?