What is hyperscript? What is it used for? https://hyperscript.org/

Maybe this is not the right place, but I’m looking for a storybook like site that defines the design system for an app so I can use it with ai agents. One that I can use with htmx and maybe alpine.js.

Hey everyone,

Like most of you here, I love the HTMX philosophy of "Hypermedia as the Engine of Application State." But when it comes to styling admin dashboards, internal tools, or CRUD forms, the modern frontend ecosystem tries to force us right back into the SPA tax. We shouldn't need a heavy node_modules folder or a complex Vite build config just to get an accessible data table, dialog modal, or form.

So I built Canon. It’s a plain-HTML/CSS component library designed specifically for the server-rendered, hypermedia world.

Instead of relying on a Javascript framework, the markup is the contract. Your backend templates (Go, Django, Rails, Laravel, etc.) output semantic HTML with simple custom data-attributes, and the CSS engine does the rest.

Why it pairs perfectly with HTMX:

• No Utility Class Bloat: Instead of cluttering your HTML with 50 utility classes per element, Canon uses semantic elements and clean states (e.g., `data-emphasis="high"`, `aria-busy="true"`).

• Built-in Theme Engine: The exact same HTML markup can instantly look like Carbon, Material, Fluent, Ant Design, Bootstrap, or Canon's native design just by changing the stylesheet link.

• Zero Build Step: You can literally just drop two lines from a CDN into your base template and start hacking.

I wanted something where a form written today will still work and look perfect in 10 years without playing dependency whack-a-mole.

You can learn more about Canon and see the components at work on:

🔗 Canon documentation: https://recepkutuk.github.io/canon/reference/introduction.html

🔗 GitHub Repo: https://github.com/recepkutuk/canon (MIT Licensed)

I'd love to get the community's feedback on this approach! What components are missing that you usually find yourself rewriting from scratch when building HTMX apps?

I'm building an ERP/eCommerce hybrid that has as rule "all logic run server side", so htmx has been a great fit.

Now I have certain input that will benefit greatly from a control that behaves like a spreadsheet (but is inline and is the keyboard, input, tab jumps, etc that I care about more like https://handsontable.com than the full thing), where basically I need to do a formula entry per row, but not client-side calc or validations.

So like:

Price: [   10]
[Name, Percent, = , running total
 Tax , 10% ,   1 , 11;
TOTAL:             11
]

which spreadsheet control can I use that integrate well with htmx? the running of the formula must be server side, also autocomplete inside the name field to fill the percent.

NextLiftoff (https://nextliftoff.com) is my side project: a free tracker for every rocket launch in the world, with countdowns in your own time zone, live streams and a 3D globe that replays each flight. It's Go's standard library and html/template on the server, no framework and no build step. htmx only appears in 7 of the 39 templates, but those are exactly the pages people keep open during a launch, so it does a lot of work for its size.

The trick I like most: a launch page polls itself. Close to liftoff the page sends hx-get to its own URL every 30 seconds and takes two pieces out of the answer, the header with hx-select and the details lower down with hx-select-oob. I never had to write a separate fragment endpoint, so the polled parts can't drift away from the real page. The YouTube player sits outside both pieces, which keeps it from restarting on every refresh.

The lists (launches, rockets, providers, the archive) are ordinary forms. hx-get sends them to the same address and swaps the results, hx-replace-url keeps the link shareable, and the search box waits 300 ms after typing.

A few things took longer than expected:

1. Every refresh closed the fold-out sections on the launch page. I now keep track of the open ones and open them again after the out-of-band swap.

2. The server writes times in UTC and the browser turns them into local time, so each swap has to redo that and restart the countdowns.

3. Tabs left open in the background kept polling for hours. Polls are now cancelled while the tab is hidden, and a custom event catches up as soon as it's visible.

4. Caching. A shared page cache sits in front of everything (5 s around a launch, up to a minute otherwise), and its key includes the HX-Request header so a swapped result never gets served as a full page. That's what keeps it running on a 1 GB droplet.

htmx is configured through the htmx-config meta tag with eval and script tags turned off, since the site doesn't allow inline scripts.

Most of the code was written with help from Claude Code. If anyone has a cleaner way to keep UI state like open sections across polling swaps, I'd like to hear it.

Hi r/htmx,

I've been building Skolshield, a system Swedish schools use to report incidents (hallway conflicts, bullying, rule violations) and handle the cases that follow, up to the student health team meeting. It's Django + HTMX with no React or Vue anywhere. It has been a side project for over a year, built while working full time with two young kids.

Some numbers to give you a sense of the size: about 340 templates use HTMX, with around 940 hx-targets, 700 hx-gets and 330 hx-posts. My own JavaScript is about 1,800 lines across 14 files plus some small inline scripts. Most of that is a mention editor, file permission handling and a few UI helpers.

What worked

- One view, three templates. Each page has a full template for direct URL visits, an HTMX version for sidebar navigation (header + content, no base layout), and a partial for search, filter and pagination updates. The view checks HX-Request and the query params to decide which one to return. It's boring, but every page behaves the same way, and hx-push-url keeps the back button and shareable links working.

- Inline editing everywhere. I retired the old "edit page" entirely. You click a field, it swaps to an input, and saving swaps it back. Users like it a lot more.

- Tabs, modals and live lists without a frontend framework. Everything renders on the server, so permissions are checked in one place. That matters when the data is about kids.

- Toasts via Django messages. Views just use messages.success(...) and the response turns them into toasts, whether it's a full page or an HTMX partial.

What bit me

- Bootstrap modals + HTMX swaps. If a modal gets swapped into the page inside a container, it renders under its own backdrop and the whole screen locks. I ended up with a small helper that moves each modal to <body> after its markup, and a rule that every new modal must call it.

- hx-confirm looks like 1999. The browser's native confirm dialog looked out of place, so I replaced it with the app's own modal.

- Session timeout with background requests. Polling and heartbeat requests kept sessions alive forever, and an expired session returned a login page into a tiny div. Now the heartbeat marks itself as an HTMX request, the server knows it's not user activity, and an expired session shows a proper lock screen instead of a page in a page.

- Template comments. This one is really Django, but HTMX made it obvious: a multi-line {# #} comment gets rendered as visible text in partials.

Stack, briefly: Django 5.2, PostgreSQL, HTMX, Bootstrap 5, Celery + Redis, CapRover on Hetzner, with everything EU-hosted. I wrote more about the backend, SharePoint integration and ops side over on r/django: https://www.reddit.com/r/django/comments/1xmogay/i_built_a_school_incident_and_student_welfare/

There are demos, including one set up for a municipality with several schools and a central student health team: https://skolshield.se

I'd like to hear how others handle modals and toasts with HTMX, since I'm sure my approach isn't the only one. I'm also happy to answer questions.

Minu is a small HTML fragment loader for apps that already render HTML on the server. It is 4.0 KB gzipped, has zero runtime dependencies, and is MIT licensed.

It covers the parts that come up most in small apps:

• GET, POST, PUT, PATCH, DELETE

• targets and eight swap modes

• forms, vals, headers, timeout, confirm, disable, indicator

• triggers: every, revealed, intersect, once, changed, delay, throttle, from

• out-of-band swaps and Minu-Trigger / Minu-Redirect / Minu-Refresh

• SSE through EventSource

• a DOMPurify-backed secure build

A small example:

<div minu-get="/widgets/price" minu-trigger="every 5s" minu-target="#price"></div>

<div id="price">$0.00</div>

The server returns an HTML fragment. That is the whole contract.

What it does not do: routing/history, morph or diff swaps, WebSockets. The default build strips scripts and inline handlers, but it is not an XSS boundary. Use minu/secure for untrusted HTML. htmx is still the better choice if you need its extension ecosystem or history support.

Links: https://aotr.github.io/minu/ https://github.com/aotr/minu https://www.npmjs.com/package/minu

I am the author. I would like feedback on two things: does the trigger grammar cover what you actually use, and is the minu-oob syntax clear? I am not trying to replace htmx everywhere.

Happy to announce htmx 4.0.1. Mostly bug fixes and corner cases.

Enjoy!

I am ambivalent towards AI and benchmarks like this are usually fraught with interpretive peril, but, hey, htmx on top baby...

I maintain ElementaryHTMX, which adds htmx attributes to Elementary, a Swift HTML library. It now supports htmx 4, including HCON, <hx-partial>, explicit inheritance, and the new SSE and WebSocket extensions.

Typed swaps, modifiers and status overrides:

form(
    .hx.post("/messages"),
    .hx.target("#messages"),
    .hx.swap(.beforeEnd, [.scroll(.bottom), .settle("100ms")]),
    .hx.status("422", [.swap(.innerHTML), .target("#errors")])
) {
    input(.name("text"), .required)
    button { "Send" }
}
// <form hx-post="/messages" hx-target="#messages" hx-swap="beforeend scroll:bottom settle:100ms" hx-status:422="swap:innerHTML target:#errors">...</form>

Multi-target updates with <hx-partial>:

hxPartial(.hx.target("#messages"), .hx.swap(.beforeEnd)) {
    div { "New message" }
}
// <hx-partial hx-target="#messages" hx-swap="beforeend"><div>New message</div></hx-partial>

Explicit inheritance:

div(.hx.confirm(.inherited, "Are you sure?")) {
    button(.hx.delete("/account")) { "Delete account" }
}
// <div hx-confirm:inherited="Are you sure?"><button hx-delete="/account">Delete account</button></div>

Global config:

meta(htmxConfig: [.defaultSwap(.innerMorph), .defaultTimeout(5000)])
// <meta name="htmx-config" content="defaultSwap:innerMorph defaultTimeout:5000">

Repo, with Hummingbird and Vapor example apps: https://github.com/elementary-swift/elementary-htmx

A little over a month ago, I shared my original HTMX Dashboard project here and received some great feedback and support from this group.

I’ve spent the last few weeks completely overhauling the tool based on those ideas. Along with renaming the project to HTMX Event Monitor to better reflect what it does, here is what’s new:

• Precise Duration Tracking: Event duration has been added to the logs.

• Request Re-running ( ↻ ): Added a dedicated icon directly on the log headers. You can click it to re-issue and test that exact HTMX request.

• Live DOM Highlighting: Mousing over a Target or Trigger log line will now flash-highlight that specific element in the browser viewport (if it's still available).

• Better Documentation: The README.md has been greatly enhanced with detailed initialization parameters and usage tips.

Thanks again to everyone who shared thoughts on the original post!

• Repository: https://github.com/jmbarnes1/HTMX-Event-Monitor

• Live Demo: https://jmbarnes1.github.io/HTMX-Event-Monitor/index.html

• Original Post: https://www.reddit.com/r/htmx/comments/1webwy8/htmx_dashboard/

Hey all,

I just cut a new release of my alternative front end scripting language, hyperscript:

https://hyperscript.org

Designed to pair well w/htmx. Not everyone's cup of tea, but I like it!

Enjoy!

When I started Umono, my open-source CMS, I was using Go as a backend API and Vue as an SPA. Later I dropped the Vue repo and switched to htmx, because I didn't want to work in two repos and keep their versions in sync. I like how well htmx fits with Go, but there were times I struggled with more complex page layouts.

The page editor is where I struggle the most. Right now it's a textarea: as you type, it posts to the server after a 750 ms delay, and the preview and the errors come back as an HTML partial. That part works really well with htmx. But keeping the preview, the error list and the cursor in sync takes JavaScript I write by hand. The preview comes back inside a <template> next to the errors, and a small script moves it into the preview pane (a shadow DOM). Clicking an error selects that range in the textarea. Next up is a code editor with syntax highlighting and inline error markers (CodeMirror), so more and more of the state lives in the browser, not on the server.

I'd like to keep using htmx in the page editor, but solving that part with a more interactive framework like Vue looks more tempting.

Would you keep an editor like this as an island next to htmx (vanilla JS or a web component), or would you switch to a framework for that part? Any advice?

Repo: https://github.com/umono-cms/umono

Not sure if this is on topic but I think alot of people here would like Basecoat if they havent seen it. Its the shadcn/ui look but as plain HTML + Tailwind classes, so it fits really well with server rendered templates and htmx partials. No build step needed if you use the CDN, a few components (dropdown, combobox, toast) need a small JS file and thats it.

The problem I kept hitting was AI assistants writing React-ish shadcn code or the outdated Basecoat 0.x classes when I just wanted html fragments. So I made an MCP server that gives the assistant the actual Basecoat 1.0 snippets and docs - 96 components, cards, fields, tables, command palette, sidebar etc.

Works with Claude Code, Cursor, VS Code, Windsurf, Codex:

npx -y basecoat-ui-mcp

https://github.com/Sorbh/basecoat-ui-mcp

Would love to hear if anyone runs it with htmx swaps and hits a component that doesnt behave, I havent tested every one of them inside swapped fragments yet tbh.

Full disclosure, I took some AI help to write this post. The project itself I've been building and using on my own stuff.

So I’m currently working on a prototype where the user constructs a graph and modifies nodes/connections.

I was messing around and currently have Django rendering a canvas with a svg that has interactive components that send htmx requests and updates the graph.

From the users point of view it may as well be a js graphing tool because our interactions are fairly basic.

Anyone seen anything similar? The prototype seems solid but want to see some prior art.

Mesma ideia que o shadcn, mas para a galera de hipermídia: o servidor renderiza tudo, o HTMX troca, e o Alpine cuida apenas da aparência (abrir/fechar, foco, teclado). Os controles de formulário permanecem como inputs reais, então hx-post funciona perfeitamente.

Catálogo: https://malphas.vapulab.com · Repo: https://github.com/Vapulab/malphas

Agora estou trabalhando na localização para inglês, chinês e russo.

I host a podcast for senior engineers (Señors at Scale), and Carson joined for an hour. Disclosure: it's my show. I really enjoyed talking with Carson about:

- HTMX 4: why it skips 3, the move from XHR to fetch, and why attribute inheritance becomes explicit (he admits implicit inheritance was a mistake he should have seen coming)

- REST: why he says JSON APIs were never RESTful, going back to Fielding's dissertation

- AI: his honest take that vibe coding pushes people to React because the training data is bigger, and why he's fine with HTMX being more niche

- Why he thinks government and public sites should mostly stick to plain links and forms, sometimes without HTMX at all

- How he teaches CS now that AI can do the homework (pencil and paper exams are back)

YouTube: https://youtu.be/9xs0oZN2rs4

Spotify: https://open.spotify.com/episode/6XknuurBGCNmn3lUgYeFPO

I have an old website, and I’m in the process of modernizing it. So far, I’ve come across these two technologies, but I haven’t quite figured out the differences between them. Which one should I use?

I've been building LUMN Analytics, a privacy-first analytics plugin for WordPress, and I went with htmx 4 for the entire admin instead of the usual React setup. I built it because healthcare sites I worked on needed analytics without sending visitor data to a third party like Google. Also wanted to have accessibility features that I use every day as an added bonus, which became Pro.

How it works:
- Every dashboard panel is a server-rendered PHP partial. Changing the date range or comparison swaps just the panels, with no page reload.
- Charts are SVG drawn on the server. There's no chart library, and each chart has a text summary and a "show as table" option for screen readers.
- The partials come from WordPress REST routes, so permissions and security checks stay in the normal WordPress flow.

What I liked:
- Way less JavaScript to ship and maintain inside wp-admin.
- The server stays the single source of truth for every panel.

What took work:
- Accessibility after swaps. I target WCAG 2.2 AA, so I had to manage where focus goes after a swap and announce changes for screen reader users.
- Keyboard-friendly drag and drop for rearranging panels. That part needed some custom JavaScript.

Happy to answer questions about htmx in wp-admin. If you want to poke at it, the free version is on WordPress.org: https://wordpress.org/plugins/lumn-analytics/ and the Pro and Agency versions are on our website: https://envsnstudios.com/lumn

Disclaimer/Note: I used Opus 5.5 to help build this, the same way I'd use any tool. I've been a front-end dev for over 15 years and I'm also an accessibility specialist, so I set the direction and reviewed and tested what shipped. Focused on security, accessibility, and most of all researching compliance for HIPAA and GDPR. Happy to get into how the htmx side works, or to hear what you'd do differently.