Less Htmx Is More

Summary

Less htmx is More October 02, 2024 It’s been two years since I wrote my first production webservice with htmx. Two years is not a very long time, but early indicators suggest that the software projects I’ve written with htmx are a much better experience for users, and orders of magnitude easier to maintain, than the software projects they replaced. They are likely to remain useful for longer than anything else I’ve ever written (so far). Pretty good! Like any new tool, especially a tool that got popular as quickly as htmx, there are differing schools of thought on how best to use it. My approach—which I believe necessary to achieve the results described above—requires you to internalize something that htmx certainly hints at, but doesn’t enforce: use plain HTML wherever possible. Once you get the hang of it, htmx starts pushing you in this direction anyway, and you start reaching for htmx less and less. It requires a mindset shift though, especially if you’re not accustomed to building page behavior with HTML features. In my opinion, most websites should be using htmx for either: Updates that users would not expect to see on a refresh (or a new page load) Updates that would also be present on a refresh (or a new page load) Everything else should use regular links and regular forms that do standard, full-page navigations. You also currently need htmx (or an equivalent library) to enable support for PUT and DELETE on regular forms. More in that in the notes section. Let’s say you’re making a website that shows today’s baseball games, and you want it to update the stats live. Here’s how I would approach that. The website’s home page should have all the currently-playing games on it, showing the live score for each one. Each of those live scoreboards uses htmx to poll the server at regular intervals for updates. Clicking on the scoreboard title (which is a regular <a> link) takes you to that game’s page, at its own URL. The game page has not just the score, but the pitc...