Live data from Hacker News

Show HN: htmz – a low power tool for HTML

leanrada.com

21–30 of 256 posts

Re: Show HN: htmz – a low power tool for HTML

#21
post #9

Given that this uses `target`, doesn't it mean that unlike htmx you can't easily make this gracefully degrade when JS isn't enabled? And, yes, I know, saying "when JS isn't enabled" in 2024 is a bit like saying "when the user is on Mars and has a 10 minute RTT" but forgive me for being an idealist.

Yeah it breaks without JS. You could add the iframe behind JS, so the target would default to a new tab. But the server would still be designed to return HTML fragments. I never found a way for a server to check if the originating request is for an iframe or a new tab. It's not quite a graceful degradation.

You could intercept the clicks with JS and add a special header, like htmx does, to return fragments, otherwise fall back to full documents.

Edit: rather than a header, dynamically adding a query parameter to the URL of the element that was clicked would probably fit better with htmz's approach.

Re: Show HN: htmz – a low power tool for HTML

#23

That's a great hack and it shows how close the browser is to offering SPA natively. Just a few attributes and we could avoid the iframe. It's probably more useful to prove a point than an actual day to day tool. And the point seems to be: htmx is too much trouble for what it offers. We just need HTML native ajax.

"Just a few attributes and we could avoid the iframe" could be the htmx/z motto

Re: Show HN: htmz – a low power tool for HTML

#24

That's a great hack and it shows how close the browser is to offering SPA natively. Just a few attributes and we could avoid the iframe. It's probably more useful to prove a point than an actual day to day tool. And the point seems to be: htmx is too much trouble for what it offers. We just need HTML native ajax.

Yes this was a response to htmx. It was a half-parody half-I wanna make it work project. Like https://github.com/vilgacx/aki

I would fear if anyone wants to use this in production BUT I would love someone to get inspired and use the concepts rather than the actual code. Hmm maybe i should write a disclaimer...

Re: Show HN: htmz – a low power tool for HTML

#26

That's a great hack and it shows how close the browser is to offering SPA natively. Just a few attributes and we could avoid the iframe. It's probably more useful to prove a point than an actual day to day tool. And the point seems to be: htmx is too much trouble for what it offers. We just need HTML native ajax.

HTML native ajax is the right approach, and what the htmx devs fully support if I understand correctly, but I don't think this demonstrates htmx is too much trouble for what it offers. It offers considerably more than what's possible here, eg. DOM morphing, animations, graceful degradation, rich event model, server side events, etc.

Re: Show HN: htmz – a low power tool for HTML

#27
post #9

Given that this uses `target`, doesn't it mean that unlike htmx you can't easily make this gracefully degrade when JS isn't enabled? And, yes, I know, saying "when JS isn't enabled" in 2024 is a bit like saying "when the user is on Mars and has a 10 minute RTT" but forgive me for being an idealist.

Yeah it breaks without JS. You could add the iframe behind JS, so the target would default to a new tab. But the server would still be designed to return HTML fragments. I never found a way for a server to check if the originating request is for an iframe or a new tab. It's not quite a graceful degradation.

> I never found a way for a server to check if the originating request is for an iframe or a new tab.

There is no such technique. One way to distinguish is to pick a URL convention and modify the URL (before the hash) of the iframe URL. For example, add ?iframe=true to the URL, and then have the server check for that. Perhaps more usefully you could include information about the parent URL, e.g. url += '?parent=${document.referrer}'. Or something.

Re: Show HN: htmz – a low power tool for HTML

#29
post #16
post #10

Earlier quoted context omitted.

If you're talking about the tabs demo, I think it's reasonable for some use cases to respect back button as previous tab. as long as it's easy to opt out.

The inline editing demo also has a separate URL for the "we're editing" state

Yeah it's terrible in some use cases.

If only HTML provided a way to navigate without adding a history entry, like .

If this was a real product i would market it as "Native time travel debugging! Go through your application state as you would go through your browser history!"

Post reply on HN