So when you modify a site and push the URL – e.g. http://domain.tld/search/?query=Javascript%20Alternative&filter=Microframework – a user would expect the same state of the page to be re-established automatically when using the link to re-open the website. For URL params like in the example above the only possible way to achieve that would be to have a JavaScript function that re-fills the fields on-load and retriggering the

HTMX

loading events. This feature is probably meant to be used with "real" pages that return the desired automatically when the link is opened – e.g. http://domain.tld/item/20/. But when HTMX is used to modify/replace a page's single sub-element, it gets quite tricky to restore that internal state without requiring on a complex JavaScript routine to re-initialize it. So I thought maybe there's a way to reinitialize it (semi) automatically by HTMX basically looping through all HTMX elements on the page and triggering the HTMX-element's event if the

hx-push-url

matches with the current one.

Has anyone had an issue with

hx-trigger:load after...

events not firing if a page was loaded through a Turbolinks

<a>

tag? Works great when I do a manual page refresh, but not if I render the page by clicking on a nav link. Clicking the link while disabling Turbolinks works perfect.

A general question for the general channel! (Sorry for the long post). When using htmx, I find myself striving a lot for "no page reloads". But today, I am wondering if it is really worth the effort, as I realize it sometimes requires small "hacks" and adaptations in my code that are specific to that goal, and that drives me away from writing "normal" web applications. In htmx,

hx-boost

is presented as a solution to avoid page reloads, to help to implement progressive enhancement, in the same mileage as Turbolinks/Turbo drive. If I understand correctly, "progressive enhancement" means to improve the experience for users when possible, and give a basic experience otherwise. In our context, I guess it means having "no reload" browsing for users having Javascript and regular browsing for others. With all the "tricks" that I used to make the "no reload" experience work, I am now wondering if my application is still usable without Javascript. For instance, I try to avoid HTTP redirections as they are not really compliant with htmx, but it has the side effect of not redirecting users that don’t have javascript. I could try to preserve the basic experience, but that would mean checking all the time

HX-Request

, and enhance or not accordingly, but still deliver the "normal" behavior if not present. I don’t know if you share my opinion on this, but I would like to receive feedback on whether you use

hx-boost

or not. And if so, do you use it sparingly, or do you try — as me — to have a full "no reload" experience? Htmx is more of a toolbox that gives you low-level primitives to deal with swapping, while apps like Turbolinks (or htmx’s

hx-boost

) are acting at a higher level, boosting the experience without you (the developer) thinking much about it. What do you think? Thanks for your feedback.

And in the end, I tend to think that it might be easier in terms of maintenance to simply boost all pages at the body level, without doing any particular low level/manual swapping in the app, and render the full body at each interaction. The server-side app would stay classic, and progressive enhancement would work out of the box. Or forget about the full "no reload" goal, and only improve small parts of the application using htmx when a reload really degrade the experience.

looks like you might need to use the

turbolinks:load

event to initialize htmx using `htmx.process`: https://htmx.org/api/#process

this is the best docs I can find on turbolinks events: https://github.com/turbolinks/turbolinks#full-list-of-events

I definitely lean "normal" web app and try to avoid too many complex setups with htmx. I don't mind pushing htmx a bit for a specific, high value UI, but by an large I'll just use

hx-boost

and let it do its thing, and if there's a spot where it doesn't work well, just turn it off.

I then look at what the high value parts of the app are and consider getting more elaborate there (e.g. lazy loading to deal w/ a slow page load, active search, maybe infinite scroll, etc.)

KISS, in summary

otoh, sometimes you have to push things a bit to find new approaches, so there is a balance to be struck

On that note – when using

hx-boost

I'd assume you're usually in a situation where you don't have full control about the application. Say the application always returned the full HTML – is it actually possible to take just one part of that response and insert it into the correlating DOM again? Basically what I'm trying to achieve looks like this – I don't want to reload the whole DOM; just

#content

.

html
<html>
<head>
  <!-- Meta -->
</head>
<body>
  <div id="app">
    <div id="header" hx-boost="true">
      <a href="/path">Reload #content</a>
    </div>
    <div id="content" hx-swap-oob="innerHTML:#content">
    </div>
  </div>
</body>
</html>

With

/path

returning the HTML above. The documentation states Note that out of band elements must be in the top level of the response, and not children of the top level elements., but doesn't provide further examples – does that mean the scenario doesn't work and in order for it to work you'd have to effectively return two elements as such?

html
<div hx-swap-oob="innerHTML:#elem">
  <!-- Content to swap OOB -->
</div>
<div>
  <!-- HTMX response for the original request -->
</div>

Of what I understand, yes, you will need to return oob elements as first children, as in your second example

So there's no way to just switch the

#content

from that response?

sounds like you might want https://htmx.org/attributes/hx-select/

(caveat: I'm quite new to htmx) I think there has to be a balance. If the user doesn't have JavaScript, htmx isn't going to work - but neither is a whole lot of other interactivity you'd likely build either. You can do forms, nav, returning all kinds of text, etc. - but even such "basic" things like enabling/disabling form elements based on a radio value rely on scripting support in the browser. And, if they do have JavaScript, then

hx-boost

and other tricks will work just fine. 🙂 post-redirect-get seems to require a page load (there's no

HX-Boosted-Redirect

header), so avoiding those does seem to be the best way to avoid page reloads. In this app that I'm migrating, I have all my boosts targeting my

main

tag, and then the server returns a header that triggers a refresh of the menu portion (with updated "active" CSS classes). Maybe that's more convoluted than just targeting the

body

tag, but I'm currently still logging on via JS, so this lets me update the menu once the user is authenticated. The advantage to avoiding a page reload is that the browser doesn't have to parse all the resources for each request (it should have them cached, but it still has to parse them); in most cases, though, that's a micro-optimization that may not have any appreciable usability gains. TL;DR - It Depends ™ 🙂

Thanks I'll have a look. Have you encountered this issue w/ Rails/Turbolinks or am I a special snowflake?

It’s a general problem w any library that inserts content into the dom “out of band”. Htmx needs to process the new content. I’ll document turbo links as an example w you today

You're a good man @User So far, I'm really digging HTMX. Way easier than stuffing some huge JS frontend library into my app for doing in-DOM content changes

BTW, follow-up from yesterday - I switched to Auth0's regular web app flow. Now you can hit F5 on an authenticated page, and everything works swimmingly! 🎉

Well, "you" being "I" - it's not done yet... LOL

good read

I would say - excellent read. Interestingly enough, following the writer's twitter feed ended me viewing a presentation by Rich Harris (Svelte) about transitional apps. He is skeptical about the 'HTML over the wire' mantra and makes some interesting points about it, although he does seem to focus on Hotwire's approach of (also) using websockets. Might be worth checking out .

Starts reasonably, gets wobbly in the middle (htmx can address every issue he cites w hypermedia) and then ends in advocating technologies that are silly levels of complexity for most apps. I’m a grug brain but edge computing is a solution for the pain of Amazon lambda like a kick in the head is a solution for a stubbed toe.

* for most apps I’m sure the nytimes is special

The spa/hypermedia split is best made on UI needs imo. Both can be fast and usable. One is way less complicated though and if it’s good enough then, we’ll, it’s good enough

Ok I’m being a little grumpy

We can agree that in the end it is all about user requirements, and with that - you pick the tool(s) suitable for the job and build something that is hopefully not too complex and maintainable. I actually wasn't that aware of the flaws that Rich pointed out in the github interface. The thing where he pointed out that on the same page you get conflicting information is pretty bad though. (and I understand that GH isn't based on htmx 🙂 )