9 ms·

> The only thing I can imagine being worse than HTMX's design philosophy Could you explain your position on this? I'm far from front-end, but from the user exp

> The only thing I can imagine being worse than HTMX's design philosophy Could you explain your position on this? I'm far from front-end, but from the user experience, current stack seems excessive and bloated. A button/link which sends a request and gets a chunk of HTML back to replace without reloading the whole page seems like a logical workflow covering the needs of 90% pages. Looks like HTMX simulates this and thus looks attractive to me.

nawgz 4y ago
Sure. > A button/link which sends a request and gets a chunk of HTML back to replace without reloading the whole page 1. My whole app is distributed now. To determine what will render after any given action, I need to go find my backend renderer for this specific endpoint, which itself seems likely to reference another piece of code that it uses as an endpoint, adding a fresh layer of indirection on every single UI interaction. Also, this HTML renderer logic needs to be aware of the rest of my app, so the reverse is true; when I'm going to write some new UI, I have to go put it somewhere random, associate it with a frontend route and backend endpoint it loads from, and then attach all the possible nested user-actions from this HTML. Have you heard of separation of concerns? This does the opposite: it joins my rendering concern with my loading concern, and distributes my User-facing concern. 2. Everything is async 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 do you show a loader in HTMX? 3. Graceful async handling So, you read my complaint #2, and said to yourself: well, I'll simply make a custom Button which upon being clicked can disable further clicks until it is updated about the status of the action it just distributed! So, real quick: where are you going to put this button so that you can easily reuse it in your other backend renderers? Are you going to write JavaScript to do this? Does it need to communicate with other parts of the app dynamically? Wow, that sure sounds like it'd be nice if I could write it once in a 'client' folder and easily pass information from its parent to it... It would also be quite cool if I could make the network layer a pure abstraction so it could be mocked... I know some libraries that help with that outside of HTMX, does HTMX have the toolkit for this stuff? CONCLUSION HTMX is "good enough" in the sense that it can produce decent static pages and bolt on a small amount of interaction. But you can't seriously tell me that you want to use UIs that require constant network round trips, and you can't tell me that you seriously want to be writing UIs that constantly require you to eject from the framework to actually make the user interactions feel good. People who like HTMX dislike good UIs, it's that simple.
- arcanemachiner 4y ago
  I came up with the following client-side solutions to problems 2 and 3 after a few minutes of Googling and RTFM: - The `htmx-indicator` class can be used to show a loading spinner while an HTMX request is in progress. - The `htmx-request` class is added to the element that makes an HTMX request. You can customize this class to disable pointer events, etc. Example: https://codepen.io/arcanemachine/pen/ExeEzgG https://codepen.io/arcanemachine/pen/ExeEzgG (Stolen mostly from https://codepen.io/davidadeneye/pen/eYVrpxg https://codepen.io/davidadeneye/pen/eYVrpxg)
- ZoomZoomZoom 4y ago
  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.
ng12 4y ago
> I'm far from front-end, but from the user experience, current stack seems excessive and bloated I see this flavor of opinion lot on HN and it always surprises me. How would you know? Kubernetes and Docker seem bloated to me, but I take good faith there's reasons to like them.
- worldsayshi 4y ago
  As a front heavy full stack Dev I concur. The debate going on lately has maybe had some important points but also been quite lopsided. I think you make a good point. Reactive frameworks are quite comparable to Kubernetes. React addresses a number of issues but not without creating issues of its own. Kubernetes seems similar in this. It also seems quite "bloated" but it seems worth it. Name a solution that adds value that doesn't also add a bunch of complexity.
  - qudat 4y ago
    I’d argue the back end is pushing a bunch of complexity to the front end and then we all wonder why it’s so complex https://bower.sh/dogma-of-restful-api https://bower.sh/dogma-of-restful-api
- stavros 4y ago
  As a backend/ops person, Kubernetes (and frontend) both seem bloated to me.

nawgz 4y ago

Sure. > A button/link which sends a request and gets a chunk of HTML back to replace without reloading the whole page 1. My whole app is distributed now. To determine what will render after any given action, I need to go find my backend renderer for this specific endpoint, which itself seems likely to reference another piece of code that it uses as an endpoint, adding a fresh layer of indirection on every single UI interaction. Also, this HTML renderer logic needs to be aware of the rest of my app, so the reverse is true; when I'm going to write some new UI, I have to go put it somewhere random, associate it with a frontend route and backend endpoint it loads from, and then attach all the possible nested user-actions from this HTML. Have you heard of separation of concerns? This does the opposite: it joins my rendering concern with my loading concern, and distributes my User-facing concern. 2. Everything is async 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 do you show a loader in HTMX? 3. Graceful async handling So, you read my complaint #2, and said to yourself: well, I'll simply make a custom Button which upon being clicked can disable further clicks until it is updated about the status of the action it just distributed! So, real quick: where are you going to put this button so that you can easily reuse it in your other backend renderers? Are you going to write JavaScript to do this? Does it need to communicate with other parts of the app dynamically? Wow, that sure sounds like it'd be nice if I could write it once in a 'client' folder and easily pass information from its parent to it... It would also be quite cool if I could make the network layer a pure abstraction so it could be mocked... I know some libraries that help with that outside of HTMX, does HTMX have the toolkit for this stuff? CONCLUSION HTMX is "good enough" in the sense that it can produce decent static pages and bolt on a small amount of interaction. But you can't seriously tell me that you want to use UIs that require constant network round trips, and you can't tell me that you seriously want to be writing UIs that constantly require you to eject from the framework to actually make the user interactions feel good. People who like HTMX dislike good UIs, it's that simple.

arcanemachiner 4y ago
I came up with the following client-side solutions to problems 2 and 3 after a few minutes of Googling and RTFM: - The `htmx-indicator` class can be used to show a loading spinner while an HTMX request is in progress. - The `htmx-request` class is added to the element that makes an HTMX request. You can customize this class to disable pointer events, etc. Example: https://codepen.io/arcanemachine/pen/ExeEzgG https://codepen.io/arcanemachine/pen/ExeEzgG (Stolen mostly from https://codepen.io/davidadeneye/pen/eYVrpxg https://codepen.io/davidadeneye/pen/eYVrpxg)
ZoomZoomZoom 4y ago
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.

ng12 4y ago

> I'm far from front-end, but from the user experience, current stack seems excessive and bloated I see this flavor of opinion lot on HN and it always surprises me. How would you know? Kubernetes and Docker seem bloated to me, but I take good faith there's reasons to like them.

worldsayshi 4y ago
As a front heavy full stack Dev I concur. The debate going on lately has maybe had some important points but also been quite lopsided. I think you make a good point. Reactive frameworks are quite comparable to Kubernetes. React addresses a number of issues but not without creating issues of its own. Kubernetes seems similar in this. It also seems quite "bloated" but it seems worth it. Name a solution that adds value that doesn't also add a bunch of complexity.
- qudat 4y ago
  I’d argue the back end is pushing a bunch of complexity to the front end and then we all wonder why it’s so complex https://bower.sh/dogma-of-restful-api https://bower.sh/dogma-of-restful-api
stavros 4y ago
As a backend/ops person, Kubernetes (and frontend) both seem bloated to me.