Is hx-boost-ing the whole body a good practice?

[ZeroAurora]

Hotwire Turbo intercepts all links in body by default, but the documentation of hx-boost shows usages on a partial html. So is hx-boost-ing a whole html body a good practice like in Turbo?

[Telroshan]

I would say both ways are neither "good" or "bad" practices, it's really up to you to pick whatever suits best your application. hx-boost was designed for both usecases so both ways exist and are supported.

Hope this helps!

[bennadel]

Sorry to resurrect an old post here, but I've been struggling with this question as well; and, frankly there's not a lot of good discussion around it on the greater web (most blog posts simply demonstrate that it can be done). After reading Who's Afraid of a Hard Page Reload, it got me thinking about removing hx-boost from my experiments. But, where I get stuck is, what if one day, I have to add boosting to a project?

If I try to build an app without hx-boost, and just do hard navigations everywhere, then suddenly, the existing application landscape becomes a liability if I didn't plan for, as an example, DOM being pulled out of LocalStorage on Back-button usage. As much as hx-boost "just works" on simple demos, even if my experiments I'm finding a lot of caveats and minutia that you have to be aware of as you're building. Which means, if you think you might need hx-boost in the future, then it almost makes sense to start using it from the onset so that you can actually build the application with this in mind.

I don't think this is an unreasonable fear. Even on the driest of internal corporate intranets, it's easy to come up with scenarios where one day Leadership wants to convert to more of a SPA experience (we have a new chat bot we need to persist, the CEO just started a podcast and we want to have the audio-player persist). And, at that moment, if you didn't build your site knowing that hx-boost caches pages in LocalStorage without taking the #fragment into account (for example) or that an HTTP DELETE with a 302 forwards the DELETE to the next page (for example), you'll almost certainly introduce subtle and/or surprising bugs if you try to drop hx-boost into an existing, robust application.

So, as much as I love the idea of not using hx-boost to keep things simple, if I think that I might one day in the future need it, it seems almost negligent to not include it from the onset.

Thanks in advance to anyone who can help me reason this out.

[Telroshan]

I know it can be tempting to "build for the future", make a "future-proof" application, but honestly, if the user's needs change, I don't find it unreasonable at all that it technically takes more than simply adding an attribute to match these needs.
On a broader sense, I would say that one should not fear refactoring. It makes things so much easier and enjoyable to build for what the user's needs are today, and to come back to it and refactor when, and if, those needs change.

What you describe here is based on "what if one day they want [X]", I would say: that's a problem for future you. If this ever happens, it would still be relatively easy to change the structure of your app to use boosting. If the app is built simple (and it's hard not to be with htmx given its technical simplicity), even another dev that would come after you could find their way through imo.

Also, I think it's important to keep in mind that boosting is no magic despite what it looks like; it's a "fast path" that you can achieve using the other htmx attributes.
Boosting is equivalent to setting the hx-target to the body, with a hx-get (or hx-post for a method="POST" form) to the same url as the element's href/action attribute, forcing hx-swap to be innerHTML, and setting hx-push-url to true.

Imo, if you were to refactor your app to feel more like a SPA, you should already answer the following question: do I need to swap the whole page? Because if you don't, you will likely not even want to boost the body anyway, and instead swap specific parts of the app.
All this can be done with regular htmx attributes and no boosting, it just takes a few more attributes than simply hx-boost, but also lets you define what exact behavior you want instead of being stuck with the boosting "magic".

Btw, you might be interested in the "less htmx is more" essay

Hope this helps!

[bennadel]

I think a lot of my anxiety comes from a lack-of-understanding of the full implications of the hx-push-url part of the whole workflow. I fear that I might have a lot of non-trivial logic revolving around the use of the location.hash (such as it might be used to power a second "layer" like a modal window). Then, if I start pushing some URLs but not others (ie, let the browser do it's natural thing), the Back Button is going to go bonkers.

I have two "North stars" when I build an app:

• The Back button shouldn't do anything surprising.
• Refreshing the page shouldn't do anything surprising.

It sounds like what I really need to do is a deeper-dive into the implications of hx-push-url when not every link is pushing a new server-side route. I don't think I could answer off the top of my head what happens when the popstate doesn't have an htmx flag on it. Let me side-quest on this thought for a moment and come back with a more informed perspective.

[bennadel]

Just sharing here for posterity. I've been trying to build up a better mental modal for how the history management works. And, I think the way the restore works is a limiting factor (in what strategies I can use). If we look at the restore, it purposely excludes the fragment from the URL it looks for:

  function restoreHistory(path) {
    saveCurrentPageToHistory()

    path = path || location.pathname + location.search

    const cached = getCachedHistory(path)
    if (cached) {

So, while I can include a fragment in my hx-push-url attribute, ex:

hx-push-url="/index.cfm#modal:/example.cfm

.. and the fragment-including value does get pushed down into the history and into the localStorage cache (/index.cfm#modal:/example.cfm), when HTMX goes to restore the DOM from the cache, it will only look for /index.cfm (less the fragment). Which results in a cache-miss and a re-fetch from the server with the HTTP header hx-history-restore-request.

What this means is that I can never use the URL fragment to capture DOM state as it won't ever be read from the DOM cache.

I was going down this path because I was hoping to maybe use the fragment as a "secondary route" for a "Layer 2" of the DOM (ie, modal windows, fly-outs, etc). I thought it might be a clean way to have two routes living side-by-side without having to, for example, stuff a secondary route into a query-string parameter, ?modal=${ encodeURIComponent( "/example.cfm" ) } kind of thing.

[bennadel]

Another thing to consider is that if a link has an hx-get, you can't CMD+Click to open that link in a new browser tab (since HTMX will call .preventDefault() on said link). It however, will allow CMD+Click if the link is merely boosted. This is another +1 in the boosting decision tree.

[bennadel]

That said, if you boost a form submission, you cannot CMD+Click to submit into a new tab. This is a potential -1 for boosting.