looks like they lazily download javascript as needed on interactions

just like htmx lazily downloads markup!

i don't know what details bundling or serialization details is, but this whole discussion makes me laugh

the existing paradigm

as opposed to the revolutionary new paradigm of serving html

\> eternal fw

roll safe: can't argue w/ silicon valley folks if u r too stupid to understand what they are sayin

@User I should mention that I set my windows location to turkey in your honor I hope you are enjoying 21 degrees C whatever that means

truly, I am the grugest of brains

little bit of "i must invent as many new concepts as possibie" syndrome there

OKOK, enough, I'm sure it's a great lib. Just not my bag, it's a big internet.

this is kind of funny. I read that. I did not understand what I can do with it or cannot do without it.

It's definitely sophisticated, to use Rich Harris' term

I think the potentially interesting concept is that it breaks things across pages/loads for you

you don't have to think about where one html block starts and another begins

of course that means you still have to keep state in the client 100% which sucks

client side frameworks reinventing so manything that ppl forget how do to state without a framework now

I achieved a pretty satisfactory solution by 1) as suggested wrapping tr "chunks" in tbody's to make it easier to target them with responses able to add/remove tr's at will and 2) changing my server side to render both my "single row" and "double row" options, instead of trying to make the second row be its own response in isolation.

@mysterious-toddler-20573 Quik was on the devtools podcast: https://devtools.fm/episode/28

in your comment did you mean that you suggesting new feature of case status code 204, oob div processed like old, page left as it is since current behaviour will wipe out target will it be valid http ?my observation: If status 200, item added, list returned, list target swapped all good. form shows with data as it is. if status 200, error, form with error returned with oob target as form, form swapped but list removed. here is where I want to leave the list as it is on page. if status 400, error forrm with error returned with oob target as form, no swapping happening at all. page shows form with no errors and list also as it is. htmx will not process response.

in the case of 204 NO CONTENT, we still process oob content

But if there's no content, why is there oob content?

I think the example was some middleware that added flash messages to a response.

That middleware should also change the response code, because the response now has content

yep, its an interesting topic

right now there is no way to signal to htmx: "Don't replace the main target content, it is unchanged, but please process these OOB responses." An empty response from the server is treated as "replace the target with nothing"

In intercooler.js, we had a distinction between an empty response, which meant "do nothing" and a response with only whitespace characters, which meant "replace with whitespace"

@User any thoughts on this? Is there another more appropriate HTTP response code for this situation?

watched it, the builder looks interesting