just that image again and again, forever

lol

I found a solution and published it here: https://stackoverflow.com/a/65569741/633961 But I have a question: Why is the http status

200

needed? If the server uses

302

, then htmx does the redirect only of the snippet. Why is providing hx-redirect not enough?

Maybe that's a shortcoming...

The documentation is correct. I changed the default during the prerelease, then had to change it again. We made another change that allowed preload to be inherited, so you could potentially set the whole document to preload links with one statement. Given that very aggressive change, I wanted to use the more conservative trigger. It still gives you an average 100ms head start in serving the request, and it’s one additional line to make it even more aggressive than that.

@User under the https://htmx.org/docs/#hyperscript examples, there is one explaining how to replicate the

X-IC-Redirect

response header in htmx. There is however a

HX-Redirect

response header listed in the htmx documentation (https://htmx.org/reference/#response_headers)?

Yeah, @User guilt tripped me into re-adding it

I should take that out

Ah. Thanks

Please dont (remove the HX-Redirect header), In my project I depend on it a lot. I understand that it can be implemented using HX-Trigger , but its a lot more sucinct

Also I would rather not use hyperscript, In its current form it feels... unstructured (im not sure how to convey this properly) where htmx feels crisp/pristine . I hope that you can keep htmx fully functional by itself, without the need for a companion library (Hyperscript) to implement core? functionality Thank you

I believe @mysterious-toddler-20573 meant that he would take out the reference to hyperscript, rather than the

HX-Redirect

response header.

@User Thank you!

@User I hear you about some of the "missing " htmx attributes, which were present before in Intercooler. At first I also found it a bit jarring, but honestly, it's starting to grow on me, especially the client-side stuff, like what

ic-action

and related attributes did, the

ic-add-class

,

ic-remove-class

, etc. If you think about it, where does it end? Do you just keep adding attributes for everything you want to do, especially client-side stuff? Why must there be a bespoke attribute for add/removing a class, as opposed to many other client side actions? Granted, the hyperscript thing does feel a little 'open-ended', compared to just looking up the appropriate attribute to do a specific thing, but ultimately I think it is the right direction. The new extension framework is also a great idea imho, because the alternative means that the core of htmx becomes bloated with stuff that's only relevant to some people or even worse, only relevant to a particular style/fashion of doing things right now, but 2/3/5 years from now, it might be completely out of fashion. I've seen this happen with many other frameworks in the past, that tried to pack too much stuff into the core framework. Ok wow... this turned into a bit of a long rant... sorry 🙈 .. I'd love to hear what other folks think of this as well

... where does it end ...

Fair point. and I totaly agree with you that htmx is better off without a deluge of attributes for every possibility under the sun. However I do think there are certain bits that are fundamentel and should be retained such as the afforementioned HX-Redirect

I love htmx as it stands, Ive spent the last 2 months migrating my project from SPA to SSR powered by htmx and a sprinkle of alpinejs and Im looking forward to creating extensions which might be usefull but wouldnt belong in the core

Yep,

HX-Redirect

is staying, I just took out the hyperscript docs showing how to reimplement it. The extension mechanism has worked out pretty well, allowing us to experiment with other ideas without blowing out the core, and the javascript api has also firmed up pretty nicely when you need to do some scripting.

hyperscript is a more speculative piece of technology and is in pretty rough shape right now. I'm in the process of removing the transpilation code that I spent a lot of time on, because I came to the conclusion that, if hyperscript is going to be useful, it will need to be because of its expressiveness rather than trying to compete with javascript.

o_O

Thank you for clarifying

https://dev.htmx.org/migration-guide/ courtesy of @User 🍻

It's obviously a work in progress... as is evidenced by the tons of TBCs (To Be Confirmed). Please feel free to correct and update! Hopefully it could be somewhat useful eventually

@User turns out I had caching turned off in dev tools, and now I have it working and the current htmx website feels like molasses compared w/ the dev site

AWESOME WORK

That's so great to hear 🙂 And that's just using the main navigation. We could put it on the whole site, just to test, if you like

in time

Dear @User Could you explain me why

defaultSettleDelay

is set to 100 by default? May I change it to zero? I couldn't find any disadvantages in my _hyperscript/htmx powered app. And MathJax (https://www.mathjax.org/#demo) re-rendering after pageload/swapping/htmx-magic is much more responsive.