4 ms·

HTMX doc is good as a reference, but not as a tutorial. This book is the missing tutorial, and it's been very useful to me. It even lead to the "A little taste

HTMX doc is good as a reference, but not as a tutorial. This book is the missing tutorial, and it's been very useful to me. It even lead to the "A little taste of HTMX" series (https://www.bitecode.dev/p/a-little-taste-of-htmx-part-1 https://www.bitecode.dev/p/a-little-taste-of-htmx-part-1). After a year of using HTMX, I really like it and would encourage everybody to give it a try. It's nice for: - internal tools - midly dynamic websites It's not great for any web page you stay a long time on mobile on, though. I made a web app with it, and on my phone, you can't handle the fact the browser plays against you if you stay a long time with a tab open and goes in and out of the app. You really need a lot of control in JS for that. Also: don't try to avoid JS using it. It's a mistake many people do, and that's not how you get the best out of it. I regularly sparkle a little vanilla js or alpine in my htmx websites to make them nicer. And in some cases, I even have one lone page that loads a full vue/react because that particular section needs to be way more dynamic. It's not an XOR. You have now a whole spectrum of how dynamic and how much work you want to put in. Sometimes, I don't write JS at all, but it's not a requirement.

dlisboa 2y ago
Can you expand on it not being great for sites with long sessions? Why does that play into it at all, wouldn’t the tab just sit there and do nothing? Do you mean if you need interactivity when the user goes in and out of the page?
- dietr1ch 2y ago
  He might be referring to the problem that URLs are not enough to get to a certain state, which you might run into when trying to share a specific view or when your browser heavily unloads your tab. I found this to be the biggest issue when building my webpage, I wanted to have a link like /blog/foo, but what exists out there is just / and the documents at /blog and /blog/foo are just the small fragments that get loaded once you click your way through / Ultimately I hacked around it by adding some js to every file beyond /, which redirected to / with some anchor, and having / restore the state through the anchor, but it doesn't look the same as regular links into a website (/#blog-foo vs /blog/foo)
  - hipadev23 2y ago
    > I found this to be the biggest issue when building my webpage, I wanted to have a link like /blog/foo, but what exists out there is just / and the documents at /blog and /blog/foo are just the small fragments that get loaded once you click your way through Huh? /blog/foo should return the full document. Why did you do it so it depends on the user clicking through links in a certain order?
  - rmbyrro 2y ago
    Can't see why you wouldn't be able to handle this with htmx. I see two scenarios: 1. User interacts triggering "/blog/foo", which should return a fragment You can add a "?fragment=true", or a custom header, or hidden input indicating the backend the desired behavior. 2. User's mobile browser reloads "/blog/foo" Respond with the entire page, including the fragments as if the user had interacted each step of the way.
    - dietr1ch 2y ago
      And now I'm stuck replicating htmx's behaviour on the server side? Seems doable and not that much of a hassle as fragment replacements should be simple afterall, but I'm simply running my site as a static page for now and I had to hack a redirecting extension for things to sort of work.
    - _heimdall 2y ago
      The "HX-Request" header is automatically included for every request triggered by HTMX. You can just check that to know if you should respond with a fragment or the full page.
      - rmbyrro 2y ago
        Thanks for pointing out. Even easier then.
        infogulch 2y ago
        If you use HX-Request header to overload routes with both normal browser and htmx requests, remember to add `Vary: HX-Request` as well, otherwise the browser may use cached htmx requests when you reload the page.
- rmbyrro 2y ago
  I didn't understand either. Depending on RAM limitations, the mobile browser will kill the tab session. When the user comes back, it'll reload the page. But I don't see how this is different for htmx or JS websites.
- BiteCode_dev 2y ago
  Unfortunately no, the tab doesn't sit there and do nothing. Mobile browsers will do all sorts of optimization, such as interrupting the network, slowing down the vm, putting it to sleep, caching and uncaching things without letting you know, and without a predictable pattern. If you use raw JS, you can deal with all kinds of errors manually, put in place recovery strategies, bust caches, etc. With HTMX, you just get sluggish behavior, or no behavior at all in your page, and you don't know why. Also like another person said, you expect your state to be the same, like the scrolling placement, but chrome might decide that no, you get a page refresh there, or you are somewhere else in the page on next switch. In this particular app, I have a raw JS counter, which is updated on the client to make it snappy, and by htmx to keep it up to date with other modifications. But the counter will be off randomly because Chrome messes with it. So I had to manually put many rules to know it's out of sync, and request the sync at the right moment. But the sync may not happen because Chromes decided so. So I should try several times, with exponential backoff, differentiates the different reasons of failures and update the DOM manually while handling various interactions with other components. At this stage, you are basically coding a lot in JS instead of getting the state from the server in HTML, so having VueJS + VueRouter + Pinia is going to be easier to manage, and you'll get more interactivity and optimistic updates on top. It's not worth it. Right tool for the right job and all that. It's mostly on mobile though. On Desktop, the HTMX app behaves perfectly.
  - rmbyrro 2y ago
    About the counter: without more details, it's hard to judge; by your description, though, it sounds to me as something you shouldn't be doing in the first place. About the state: there are plenty of ways to have a polymorphic backend responding with fragments or entire HTML pages, depending on state and what's required by the request. Can't see the limitation you guys are talking about. About the scrolling position, it's actually dynamically loaded content that messes everything. Browsers do a pretty good job keeping scrolling position, as long as the page loads with the same content as before. Which is easy with htmx and very hard to impossible with dynamic content.
    - patates 2y ago

dlisboa 2y ago

Can you expand on it not being great for sites with long sessions? Why does that play into it at all, wouldn’t the tab just sit there and do nothing? Do you mean if you need interactivity when the user goes in and out of the page?

dietr1ch 2y ago
He might be referring to the problem that URLs are not enough to get to a certain state, which you might run into when trying to share a specific view or when your browser heavily unloads your tab. I found this to be the biggest issue when building my webpage, I wanted to have a link like /blog/foo, but what exists out there is just / and the documents at /blog and /blog/foo are just the small fragments that get loaded once you click your way through / Ultimately I hacked around it by adding some js to every file beyond /, which redirected to / with some anchor, and having / restore the state through the anchor, but it doesn't look the same as regular links into a website (/#blog-foo vs /blog/foo)
- hipadev23 2y ago
  > I found this to be the biggest issue when building my webpage, I wanted to have a link like /blog/foo, but what exists out there is just / and the documents at /blog and /blog/foo are just the small fragments that get loaded once you click your way through Huh? /blog/foo should return the full document. Why did you do it so it depends on the user clicking through links in a certain order?
- rmbyrro 2y ago
  Can't see why you wouldn't be able to handle this with htmx. I see two scenarios: 1. User interacts triggering "/blog/foo", which should return a fragment You can add a "?fragment=true", or a custom header, or hidden input indicating the backend the desired behavior. 2. User's mobile browser reloads "/blog/foo" Respond with the entire page, including the fragments as if the user had interacted each step of the way.
  - dietr1ch 2y ago
    And now I'm stuck replicating htmx's behaviour on the server side? Seems doable and not that much of a hassle as fragment replacements should be simple afterall, but I'm simply running my site as a static page for now and I had to hack a redirecting extension for things to sort of work.
  - _heimdall 2y ago
    The "HX-Request" header is automatically included for every request triggered by HTMX. You can just check that to know if you should respond with a fragment or the full page.
    - rmbyrro 2y ago
      Thanks for pointing out. Even easier then.
      - infogulch 2y ago
        If you use HX-Request header to overload routes with both normal browser and htmx requests, remember to add `Vary: HX-Request` as well, otherwise the browser may use cached htmx requests when you reload the page.
rmbyrro 2y ago
I didn't understand either. Depending on RAM limitations, the mobile browser will kill the tab session. When the user comes back, it'll reload the page. But I don't see how this is different for htmx or JS websites.
BiteCode_dev 2y ago
Unfortunately no, the tab doesn't sit there and do nothing. Mobile browsers will do all sorts of optimization, such as interrupting the network, slowing down the vm, putting it to sleep, caching and uncaching things without letting you know, and without a predictable pattern. If you use raw JS, you can deal with all kinds of errors manually, put in place recovery strategies, bust caches, etc. With HTMX, you just get sluggish behavior, or no behavior at all in your page, and you don't know why. Also like another person said, you expect your state to be the same, like the scrolling placement, but chrome might decide that no, you get a page refresh there, or you are somewhere else in the page on next switch. In this particular app, I have a raw JS counter, which is updated on the client to make it snappy, and by htmx to keep it up to date with other modifications. But the counter will be off randomly because Chrome messes with it. So I had to manually put many rules to know it's out of sync, and request the sync at the right moment. But the sync may not happen because Chromes decided so. So I should try several times, with exponential backoff, differentiates the different reasons of failures and update the DOM manually while handling various interactions with other components. At this stage, you are basically coding a lot in JS instead of getting the state from the server in HTML, so having VueJS + VueRouter + Pinia is going to be easier to manage, and you'll get more interactivity and optimistic updates on top. It's not worth it. Right tool for the right job and all that. It's mostly on mobile though. On Desktop, the HTMX app behaves perfectly.
- rmbyrro 2y ago
  About the counter: without more details, it's hard to judge; by your description, though, it sounds to me as something you shouldn't be doing in the first place. About the state: there are plenty of ways to have a polymorphic backend responding with fragments or entire HTML pages, depending on state and what's required by the request. Can't see the limitation you guys are talking about. About the scrolling position, it's actually dynamically loaded content that messes everything. Browsers do a pretty good job keeping scrolling position, as long as the page loads with the same content as before. Which is easy with htmx and very hard to impossible with dynamic content.
  - patates 2y ago