(Semi) random question: does HTMX function with It's full range of features (like for instance hx-select) in static site generators like Hugo or Jekyll? Or does it need a dynamic backend for that?

Hi guys, i want to ask about htmx error. I got error in console insertBefore and removeChild. What is that error causes?

Can you please post a screenshot?

htmx should work fine w/ a static site, although you there isn't any dynamic server side behavior available obviously.

all htmx wants back from the server is html

if your backend can produce it, all good

I'm about to share this with the team at work - one thing that just came to mind is that htmx completely eliminates the "two versions of models" issue, when you have your server-side language with one representation, then the equivalent in TypeScript on the client. With htmx, the client just gets the user-facing representation!

Yep! We serve hypermedia representations of the serve data for users to interact with statelessly. I know it sounds crazy, but it just might work!

this definitely takes pressure off adopting javascript/typescript on the server side (ie. "We already have client side models for stuff, why have different server side models in some other language?")

The first time I did a SPA, I didn't even bother with client-side models. "I'll just run through it with the console open; if I changed the definition and forgot to update the client, I'll find it." Fine for a hobby project (especially back then); not so great now.

many such cases

The Svelte guy was very eloquent (as always), but like @mysterious-toddler-20573 said – most of the arguments he used against “transitional apps” where centered around maintaining parts of the page while refreshing other parts… htmx neatly solves all of those. That’s probably because he used Hotwire as the gold standard for “transitional apps”… this is where the lower–level utility of htmx really shines. Here’s where I am in my “SPA vs Multi-page app” journey: – I have serious app-envy when it comes to apps like Superhuman (yes I happily pay $30/month for an email client, don’t @ me) and Linear, not gonna lie. – I also subscribe to hey.com for $99 a year… mostly because I’m curious to see how that app evolves, not because I actually use it. – For the apps we build in our business: it’s a mix of Vue, React and htmx + hyperscript apps. 1. React, for an internal-only app, because thats what the junior dev that wrote it knew and is comfortable with. 2. Vue, because it was a greenfields app with a very thin model layer and the devs working on it were comfortable with Vue. 3. Htmx + hyperscript for our older, Java, MVC, flagship B2B SaaS fintech product, which has a ton of server-side logic, rules and validation that I wouldn’t dream of trying to implement client-side only. So for me the answer is: it depends.

Is there a story for the post-redirect-get that htmx could intercept and prevent from doing a full page refresh? Inline edit eliminates that need, but if you have a standalone "edit" page (say, maybe you're launching it from another place in an "add" mode, or you want a URL history entry for it) - the POST would go to the item endpoint, but then the follow-on page would ideally look like an htmx-boosted click, and once again push a URL into history. Is there a combination of things I've missed than enables this flow, or would that be "doing it wrong"? (Or, in these cases, do we just accept that we're going to get a full page refresh?)

We certainly use the post–redirect–get pattern extensively with htmx, without full page refreshes. We use boosted forms to push the url change, the idea being that the user can at any point do a forced page refresh and land back on the correct place

I’m trying to think if we do anything special to make this work, I don’t think we are?

By "boosted forms", are you talking about putting hx-boost on the form tag, along with hx-post? I don't think I've tried that combo.

We just put hx–boost on a higher level in the page structure but yes, it’s essentially the same as having a bog–standard form and adding just the hx–boost=“true” attrib on the form tag, yes

With hx–boost you don’t need to specify hx–post separately. You can check this yourself by inspecting the rendered html, you notice that the htmx attributes are auto added to the form tag, including hx–push etc

OK - I'll play with it some more. Now that I think about it more, I think I put hx-boost on my nav bar, but didn't do it within

main

(which is what I'm targeting with

hx-swap

on those links). If it's as simple as that - that will be really nice!

This is our top nav:

<div id="nav" hx-boost="true" hx-target="#main">

That's it 🤷‍♂️

(yes - target, not swap...)

Oh sorry, technically we do put the hx-boost attrib on each form tag as well. This is just because occasionally we cancel boost to do custom stuff. So the hx-boost on top nav is for the nav get's .. here's our generic form tag (the #{form ..} bits is server-side groovy syntax):

#{form _arg, 
           id:_id,
           (_enctype ? 'hx-encoding' : 'na'):_enctype, 
           "hx-boost":"true",
           "hx-target":"#main",
           "hx-trigger":"submit" + (triggerFilter ? "[" + triggerFilter + "]" : ""),
           (noValidationSpecified ? "noValidation" : "na"):_noValidation, 
           "script":"on htmx:responseError(xhr) call displayErrorMessage(xhr.responseText) end
                     on htmx:afterRequest call enableSubmit() end"}
           
        #{doBody /}
        
    #{/form}

As you can see we have some extra trigger filters and client-side validation going on.. but server-side, there's nothing... if you don't boost a form, it will do a regular post then redirect + get, with boost, it all just works without any page refresh.

@User let us know if you managed to get it working as expected 🙏

Just sharing a quick remark here. When using

hx-boost

on the body, I was told before that the server could render a full HTML response (with

head

and so on), but it was better to just render the content of the body (the innerHTML of the body). However, this has one drawback: the

<title>

is not present anymore in the response, and htmx does not update the title of the page anymore. I would need to re-include the

<title>

alongside the content of the body, but it makes poor reusability in my templates, as I need conditional or a specific layout for that. I think I will turn back and let the server render the full response anyway.

I’ve been juggling this idea too. I have worked my server to serve partial pages or full responses base on hx- headers. And, you could probably use a hx-oob-swap to switch out the header. But I wonder how much work I’m really saving on my server. It may just be simpler to serve/cache a whole page and be done with it.

I didn't realize it updated the title if it was present; I've been pushing the title in a response header, and have an

afterOnLoad

handler updating it based on that. 🙂 I have lots of things to learn!

Yes, it is a handy feature, but not really discoverable as not super "common". A title is usually expected in the

<head>

. I personally render it at the top when rendering partials, followed by potential oobs and eventually the main content for the target of the swap.

I am exactly asking myself the same kind of questions those days 😃 . I tend to often compare with how people do in hotwire/turbo, as it starts to gain in popularity and good practices might emerge from there. And I feel that the main interest of libraries such as turbo drive or htmx is to accelerate developments by focusing on your backend tech of choice. Turbo frames for instance are automatically swapped by the matching frame id from the response (aka

hx-select

in htmx). It is definitely more opinionated than htmx, but the goal seems that you can continue to send pretty much the full page on the server. That’s why I am thinking about sending the full page most of the time (alongside with

hx-boost

) and only doing partials to enhance some parts of the application. And as for the

<head>

, I guess it does not cost way more bytes in the response, and it avoids having to do conditionals on the server to render only the body. Your app stays more techno agnostic. In the end, htmx is for any backend tech, but I guess the opposite should also be true. Your backend tech shouldn’t be too coupled to your frontend libs...

I agree with the spirit of what you said @User . In our case... there's a boatload of stuff sitting in the head, so we really don't want to pull that down on every page load, so it's partials to swap out a stable div in the body all the way. Server-side we of course have to have a bit of logic to decide when to send the full page or the partial, but it's trivial and done in a single place, since we have nice server-side templating available. In the end, as with most things like this, the best answer is: it depends 😁