4 ms·

1. > adding a fresh layer of indirection on every single UI interaction. Well, if it's a web app, getting the data from the server is inevitable. If it somehow

1. > adding a fresh layer of indirection on every single UI interaction. Well, if it's a web app, getting the data from the server is inevitable. If it somehow can work without it, maybe it shouldn't be a web app? Or, as a last resort, it should be able to communicate the same way with the executable payload you served with the UI. If it's pure UI interaction you have the whole html+css at hand, it's huge and is rumored to be so capable, that people want to layout desktop UI's with it now. 2. > You know what I love as a user? When I have to wait for a network trip before the Button I clicked on does anything. How can it do anything if it doesn't get a response from the server? > But you can't seriously tell me that you want to use UIs that require constant network round trips. Well, network roundtrips are often measured in ms, but a fat modern UI brings a netbook capable of compiling a kernel in less than half an hour to a crawl. Don't get me wrong, I get some of your reasoning, but the issue is that functionality necessary for all these requirements you mention bleeds into basic hypertext model of the web and we get a byzantine chaos of today. So, we get blogs showing blank pages if JS is turned off, pages that won't show you the content unless you scroll and hover for a few seconds over each chunk of the page and all that insanity. PS: It's easy to put people in boxes but it's never that simple.

nawgz 4y ago
> 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.
- ZoomZoomZoom 4y ago
  Ok, thanks a lot for the detailed answers. I see we're coming at it from totally different angles. Can't say I'm 100% convinced but I'll be refining my understanding of the topic and my position further.

nawgz 4y ago

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

ZoomZoomZoom 4y ago
Ok, thanks a lot for the detailed answers. I see we're coming at it from totally different angles. Can't say I'm 100% convinced but I'll be refining my understanding of the topic and my position further.