# 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.

Source: https://www.jpkc.com/db/en/blog/htmx-reihe/

[htmx](https://htmx.org/) 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](https://www.jpkc.com/db/en/demo/event-calendar/).

## The series

1. **[htmx in context: HTML over the wire instead of JSON](https://www.jpkc.com/db/en/blog/htmx-einordnung/)**: 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.
2. **[What crawlers and AI see of htmx content: a measurement](https://www.jpkc.com/db/en/blog/htmx-crawler-geo/)**: check marks measured via `curl`, in a headless browser and with an AI assistant. Why `load`, `revealed` and buttons with `hx-get` stay invisible to AI crawlers, and how robust URLs solve the problem.
3. **[htmx and accessibility: what gets lost when HTML is swapped](https://www.jpkc.com/db/en/blog/htmx-barrierefreiheit/)**: 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 `curl` and 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](https://www.jpkc.com/db/en/blog/htmx-einordnung/) is the place to start. If you want to know whether your content can show up in AI answers, read [Part 2](https://www.jpkc.com/db/en/blog/htmx-crawler-geo/). 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](https://www.jpkc.com/db/en/blog/htmx-barrierefreiheit/).

## Further reading

The reference is the [documentation on htmx.org](https://htmx.org/docs/); the freely readable book [“Hypermedia Systems”](https://hypermedia.systems/) explains the idea behind it. Related articles on this blog: [Writing for AI](https://www.jpkc.com/db/en/blog/schreiben-fuer-ki/) and [What is GEO?](https://www.jpkc.com/db/en/blog/was-ist-geo/) on visibility in AI answers, and [HTML landmarks in practice](https://www.jpkc.com/db/en/blog/html-landmarks/) on the accessibility of page structure.