Possibly relevant: https://bitbadger.solutions/blog/2023/page-level-javascript-initialization-with-htmx.html (there's a disconnect between afterSwap and afterSettle there, but the concept is the important part here). TL;DR - htmx fires different events that can do the same thing as

DOMContentLoaded

.

php
abort(
    code: 418,
    headers: [
        'HX-Refresh' => 'true',
        'HX-Redirect' => route('projects.show', $project),
    ]
);

Hi! I am here because I think htmx is great.

FWIW, issue was that because I used a redirect helper in my backend, a

Location

header was added to the response headers, making the browser do something that messes all the headers up.

So the

hx-*

headers were present in the response headers in the network tab of that request, but

xhr.getAllResponseHeaders()

did not contain those headers. 🤷‍♂️

I think I spoke too soon, the issue is not fixed and still fully reproducible on the site and as shown in the video I uploaded.

Checking this one out

@mysterious-toddler-20573

getCacheBusterParam

(I'm lazy) seemed to have solved it, thank you 🙏

In a project of mine I tried to serve htm(x)l responses to the front-end using a service-worker. It works. (for the clojurist: I used shadow-cljs to compile the project. The service worker forewards requests to a Reitit router! I just wrote few helper functions to deal with js responses and btw it would be amazing to run a ring router inside a service worker) Of course it works. The only issue is that the very first time you require the page you have to wait for the service-worker to be installed before proxying the requests to the service worker. So, I wanted to ask you, do you think that the service-worker architecture makes sense with htmx? In seems to me that there could be a lot of possibilities. To begin with, since you have a service worker the application could easily result in a PWA without much effort. Second, the service worker can directly communicate with the pages it controls: that is to say each page gets a "server-sent-like" event for free (server side events could be implemented in the service worker) through the postMessage API of the worker. Third, you might be allowed to choose the front-end technology you prefer but for some human / business reason it's impossible for you to work on the backend and you are 'doomed' to the traditional json data api. In this case the service-worker would intercept whichever API, doing some cahcing and finally returning the htm(x)l response to the client. As we would like. I started playing with this idea because it's a cheap solution one can deploy on a CDN (for free on github page for instance) as if it were a SPA. It could also be a static web-site with a "backend", why not? It does not matter. Whatever it is it can benefits from what htmx does and it is not really hard to implement. Sorry for mucho text, I just wanted to share with you this thought. Finally a last question .. do you think an extension targeting events from the postMessage api could be useful in general?

Hi Wim, did you find any workaround for your problem? I have the same with a selectpicker.

Huh, that's funny, I was convinced HTMX followed the hydration principles a bit more, since instead of event delegation you eagerly attach event listeners to every element which declares it needs one with

hx-trigger

(or implicitly if it has a valid

hx-<verb>

tag I guess)

I keep going back and back to this blogpost and thinking about how it could be applied to HTMX, but does it really need to be applied at all?

"the existing paradigm" as opposed to the brand new paradigm of generating HTML in response to requests

Qwik actually embraces HTML-over-the-wire in its fullest.

Having global event listeners for literally everything seems like a waste to eagerly setup ~30 listeners for all possible user events, and some of those behave differently when attached globally like

mouseover

and

mouseenter

...

there is no overhead in htmx, because we don't try to use the same code on server and client

Sure it maybe it makes sense for big table elements with lots of elements each requiring interactivity

so there's no repetition that needs to be avoided (which is what Qwik boasts)

instead of trying to abstract away the server/client barrier, htmx apps are architected around it

because of the clientside behaviours being directly implemented declaratively with attributes in the returning HTML, right.

yep

But I'm referring to just that one blogpost about if whether attaching tons of event handlers over and over is a good idea (maybe I got the main point of the blogpost wrong though 😂)

the server declares what behavior should exist, and the client (browser+htmx) actually does that behavior

i think the blogpost is saying: SPA frameworks (that are not qwik) need to re-execute the code that created the elements on the server to know where to attach the listeners

whereas in htmx it's just a

querySelector

right

yeah that makes sense

using htmx really makes me forget just how terrible the end UX is with how things are structured

Render a nonexistent HTML -> Send to Client -> Client downloads several large JS bundles, some of them synchronously -> Client takes a long while to parse -> Client requests actual data from server -> Server returns JSON(s) -> Client parses JSON(s) -> Client creates the DOM through JS (very slowly!) and registers all event listeners -> and much more...