You mean, the htmx?

the _ attribute is a hyperscript attribute

brother project of htmx. the half-crazed, half-genius brother.

Omg, of course not, thanks! Terms like hyperscript are still magic to me

Now it works, thank @boundless-vase-80440

Thank @ripe-action-67367 , he dropped the clue

🙂

How qwik works very much reminds me of htmx

Except if I'm not wrong htmx does use hydration?

AFAIK, both these terms are tightly related with modern client-side-rendered JS frameworks when dealing with SSR. They are not really applicable to htmx since htmx does not do client-side rendering as part of its normal operation at all (by default that is). It simply scans DOM tree and sets up event listeners on elements based on attribute values. Whether it fits definition of "hydration" or "resumability" I don't know, but considering drastically different models htmx and frameworks use, I'm hesitant to say so

And what client-side rendering htmx can do is done with extension and much, MUCH simpler than what Frameworks do

being a memetard

Well at the very least having global eventlisteners and finding elements dynamically seems smarter than registering event listeners for everything

Something I've had an issue with is somehow getting SSR for the few client-side bits that I need when using htmx. SEO is very important so I can't really go without SSR. And I definitely don't wanna use a JS backend, heh.. so that's a bit annoying

Why can’t you just render the client side stuff on the back end and deliver it in html?

(Not in the JSland “SSR” way, but the original web “hypermedia” way)

Not sure what you mean. If I do that, I'm basically limiting myself to using vanilla js for DOM modification, whereas I'd preferably use a more complete framework..

And those need the "SSR and hydration" stuff.

Hard to get into the detail, without knowing what you’re doing but htmx is modifying the DOM (just not in the same way as JS frameworks) and it can do an awful lot. For the true client-side stuff _hyperscript or alpineJS can do that. However, as you might know, the point of htmx is that there should be very little you need to with JS, because you’re using a hypermedia approach to fetch rendered HTML from the back end. I suppose what I’m saying is that JSLand SSR and Hydration are only required because of the SPA approach. htmx doesn’t require them and if your use of htmx does, then there’s a strong chance you could be using it wrong.

There's a lot of interactions that don't warrant a server request, so that's the use case I'm talking about. I'm not convinced alpine would be enough for what I need is all, so maybe it's a safer bet to go with an API + frontend approach.

maybe vue or petite-vue for the stuff that htmx doesn't work for? https://github.com/vuejs/petite-vue

I did consider those, but they have the same issue unless I mount the vue app to the innerhtml, and if I do that, variables will show up

{{ like this }}

until js loads which is kinda janky

😑

I'm an HTML guy, myself

I don't have much love for js, but I do realize it might be the better way to go for my use case..

What I would do is a proof of concept: select the client side bits that you are most afraid of and give them a shot with htmx+alpine.

that's what I do when I start to speculate too much.