> 1. getting the data from the server is inevitable I don't think you really read what I wrote. It is the CODE angle that I am addressing here; there is indire

> 1. getting the data from the server is inevitable I don't think you really read what I wrote. It is the CODE angle that I am addressing here; there is indirection in every piece of UI code because of what I said. It never is a piece of markup that is conditionally displayed based on state; it is the result of another hx-request, so I can never escape walking thru a graph that includes my entire UI and my entire backend while trying to build my UI. Yuck. > 2. How can it do anything if it doesn't get a response from the server? First of all, let's hope we all agree that each user action needs to be acknowledged and represented well by the UI. HTMX supports the most bare-bones "request is in flight" type of logic, but I usually like optimistic app behaviors when on the happy path. For instance, an object you created can show up in a list instantly even though the list came from the server. It's really easy to do this kind of stuff in normal UI frameworks, but HTMX outlaws it entirely. On the flip side, I do want to acknowledge this point: > we get blogs showing blank pages if JS is turned off HTMX has a use-case, like I acknowledged: 'HTMX is "good enough" in the sense that it can produce decent static pages and bolt on a small amount of interaction' This use-case definitely applies to things like blogs, but we have to be honest with ourselves. Blogs and this entire class of website aren't really a "user interface" or application so much as they are user-facing markup. Static content. I wouldn't call myself a "long-time UI guy" if I was building blog templates for a living. HTMX falls apart the second you're building tools, if you care about the tool-user's experience as much as the tool developer's.