Show HN: htmz – a low power tool for HTML

Overall reaction & intent

• Many find htmz impressively small, elegant, and a clever demonstration of deep platform knowledge.
• It’s repeatedly framed as a “fun hack,” “experiment,” or even parody of heavier frameworks, though some would still consider it for small real projects.
• Others view it as technically neat but confusing or brittle to debug, and not something they’d want to inherit in production code.

Relationship to htmx and other tools

• htmz is widely described as a subset / one‑liner reimplementation of core htmx behavior (server‑rendered fragments swapped into the DOM).
• htmx is noted as heavier because it adds history support, event/callback systems, DOM morphing, SSE, input gathering, and graceful degradation; that’s framed as both a feature and a cost.
• Comparisons are drawn to pjax, Vue (often praised for “scaling down”), Alpine, hyperscript, and other “HTML-first” or micro frameworks.

Mechanism & HTML semantics

• Core trick: use <base target> and a hidden <iframe> as a proxy; links/forms target the iframe, whose loaded fragment is moved into the main DOM based on the URL hash.
• Some see the reuse of fragment identifiers (#id) and the original use of <slot> as semantic abuse; others argue this is acceptable hackery consistent with iframe behavior.
• Suggestions include using inert elements like <div> or <output>, and alternative query selector patterns to shrink the snippet further.

History / back button behavior

• Multiple commenters note that each click adds a browser history entry, breaking expected Back behavior and polluting history.
• Proposals: use buttons instead of links, use replaceState, or an “extension” to manage history; some think history quirks are acceptable for demos but bad UX for real apps.

JavaScript dependence & graceful degradation

• htmz breaks entirely without JS; it also behaves poorly when users open links in new tabs or copy link targets.
• There is extensive debate on whether non‑JS support still matters:
  • One camp insists progressive enhancement and “HTML-first, JS as upgrade” are important for accessibility, privacy, and low‑power/legacy devices.
  • Another camp argues that disabling JS is equivalent to disabling part of the browser, so breakage is acceptable.
• Various strategies are proposed: dynamic base tag insertion, special query params, cookies, and the new Sec-Fetch-Dest: iframe header to distinguish full pages vs fragments.

Performance & UX tradeoffs

• Some worry about round‑trip latency for every interaction (e.g., switching tabs) and say such interactions should be purely client‑side.
• Others counter that small HTML fragments over the network can outperform large JS bundles, and that modest delays are acceptable in many regions and use cases.
• Hybrid ideas emerge: server‑rendered HTML for most flows, with small client‑side scripts (or things like hyperscript/Alpine) for local, zero‑latency interactions.

Security, CSP & cross‑origin concerns

• Inline onload and iframes can conflict with strict Content-Security-Policy; workarounds like nonces or hashes are mentioned.
• Cross‑origin variants using postMessage are suggested but flagged as dangerous if targetOrigin: '*' is used, since it can leak iframe content.

Broader platform discussion

• Several commenters see htmz as evidence that “HTML-native AJAX” or fragment-loading should be standardized.
• References are made to existing proposals (e.g., an html-include element) and to the idea of a new fragment MIME type.
• There’s nostalgia for pre‑SPA iframe/XHR hacks and a sense that modern UI stacks overcomplicate what basic hypermedia already does well.