27 ms·

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 t

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
  > 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 For example to implement an infinite scroll, you can use the htmx DSL to load additional rows like this: https://htmx.org/examples/infinite-scroll/ https://htmx.org/examples/infinite-scroll/ If I did this with react, I can use a session storage caching plugin, so how do you prevent the chain of load events on history back and page refresh with htmx? Now you are looking at service workers... I mean with a bit of extra JS and some additional APIs, nothing is strictly impossible but it's often that you go back to the architecture board when you are working with it. I don't dislike it though, not even close. React (and other similar tools) has (have) a place, so does htmx.
  - rmbyrro 2y ago
    Why can't the number of rows loaded be stored in the URL? You could use hx-push-url [1] every time the scroll triggers loading more rows, updating the total number of rows loaded. When the browser refreshes the page, the backend will know how many rows to return. No need for complicated JS plugins and service workers. Just basic browser feature, HTTP and HTML. You have fewer ways of shooting your own foot. I think the modern frontend environment have a tendency to look for over complicated solutions. Most times I see people proposing JS to manipulate the browser, a simpler browser-based solution would be perfectly good. In most cases when I browse the web, the JS manipulation leads to very poor UX. Even when the developer is exceptionally good and can deliver better solution than the browser, the advantage gain is so small that it's not worth the effort. Unless you're Facebook and can dillute the high-quality development cost to billions of users. [1] https://htmx.org/attributes/hx-push-url/ https://htmx.org/attributes/hx-push-url/
  - wild_egg 2y ago
    Service workers seems like overkill HTMX has pretty simple controls for pushing history state from either the client or the server for each request. Add the current page into the URL every time you load a new section and when someone hits 'back', they can be given exactly the same content as they had before

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
> 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 For example to implement an infinite scroll, you can use the htmx DSL to load additional rows like this: https://htmx.org/examples/infinite-scroll/ https://htmx.org/examples/infinite-scroll/ If I did this with react, I can use a session storage caching plugin, so how do you prevent the chain of load events on history back and page refresh with htmx? Now you are looking at service workers... I mean with a bit of extra JS and some additional APIs, nothing is strictly impossible but it's often that you go back to the architecture board when you are working with it. I don't dislike it though, not even close. React (and other similar tools) has (have) a place, so does htmx.
- rmbyrro 2y ago
  Why can't the number of rows loaded be stored in the URL? You could use hx-push-url [1] every time the scroll triggers loading more rows, updating the total number of rows loaded. When the browser refreshes the page, the backend will know how many rows to return. No need for complicated JS plugins and service workers. Just basic browser feature, HTTP and HTML. You have fewer ways of shooting your own foot. I think the modern frontend environment have a tendency to look for over complicated solutions. Most times I see people proposing JS to manipulate the browser, a simpler browser-based solution would be perfectly good. In most cases when I browse the web, the JS manipulation leads to very poor UX. Even when the developer is exceptionally good and can deliver better solution than the browser, the advantage gain is so small that it's not worth the effort. Unless you're Facebook and can dillute the high-quality development cost to billions of users. [1] https://htmx.org/attributes/hx-push-url/ https://htmx.org/attributes/hx-push-url/
- wild_egg 2y ago
  Service workers seems like overkill HTMX has pretty simple controls for pushing history state from either the client or the server for each request. Add the current page into the URL every time you load a new section and when someone hits 'back', they can be given exactly the same content as they had before