The htmx Series: HTML over the Wire, Placed in Context, Measured, Tested
Overview of my three-part htmx series: context against Unpoly and native tools, visibility for crawlers and AI, accessibility. With a live demo.
by Jean Pierre Kolb ·
htmx (opens in a new tab) promises modern interfaces without a JavaScript framework: the server sends HTML, and a few attributes swap parts of the page. A lot has been written about the idea. I wanted to know how it feels in practice, and above all what it means for two topics that matter to me: visibility for search engines and AI systems, and accessibility. This page is the entry point and table of contents of the series.
Why a series that measures
Before this series I had not used htmx in any project. So instead of writing down an opinion, I built a demo and measured against it: a fictional event calendar, built robustly with htmx, with Unpoly and with no library at all, plus one deliberately fragile htmx build. Every content block carries a check mark that shows who gets to see it. The demo is live, and you can re-run every measurement of the series there: Demo: Event Calendar.
The series
- htmx in context: HTML over the wire instead of JSON: what htmx is, the same feature in htmx, Unpoly and with no library, Turbo, Datastar and fixi in brief, pitfalls with CSP and
eval, and a guide to choosing. - What crawlers and AI see of htmx content: a measurement: check marks measured via
curl, in a headless browser and with an AI assistant. Whyload,revealedand buttons withhx-getstay invisible to AI crawlers, and how robust URLs solve the problem. - htmx and accessibility: what gets lost when HTML is swapped: through four builds with the keyboard. Where focus lands, why title and language can go wrong, what Unpoly and
<dialog>handle for you, and what the European Accessibility Act has to do with it.
The key findings
- htmx is small and free: 16,838 bytes minified and gzipped, no dependencies, 0BSD licence. Unpoly brings more ready-made building blocks, and its JavaScript is just under three and a half times the size.
- What is in the first response is what is visible. As long as every state has a real URL, everything was in the first response in my measurement, visible to
curland to an AI assistant as well. What htmx loads later via JavaScript is not seen by most AI crawlers. - Accessibility remains your job. In the robust demo, focus fell to
<body>after a tab switch and after “load more”, htmx took over foreign page titles and left the language declaration unchanged. htmx has a setting for each of these, but only if you know about it.
Who it is for
If you build server-rendered applications and are thinking about making them livelier with little JavaScript, Part 1 is the place to start. If you want to know whether your content can show up in AI answers, read Part 2. If your application falls under the European Accessibility Act, or you simply want it to be usable by everyone, there is no way around Part 3.
Further reading
The reference is the documentation on htmx.org (opens in a new tab); the freely readable book “Hypermedia Systems” (opens in a new tab) explains the idea behind it. Related articles on this blog: Writing for AI and What is GEO? on visibility in AI answers, and HTML landmarks in practice on the accessibility of page structure.