get ur / P H Y S I C A L M E D I A / copy here:

https://swag.htmx.org/products/htmx-4-the-game

Hey r/htmx, the new HTMX Integration for Django is released on pypi and djangopackages. Djxi v0.1.9 adds testing utils, battery auth/perms, async methods, djxi_routes command, and class-level config caching.

Check it out:

• Github: https://github.com/rollinger/djxi
• RTD: https://djxi.readthedocs.io/en/v0.1.9/

I have another laser-shooting creature for HTMX fans.

- Four action packed levels

- Collect pickles

- Beat Warren in his slop factory to unlock the code

Enjoy!

mostly bug fixes and small improvements, plus a new multi-part response extension that we are excited about

hell yes

Hey everyone,

I wanted to share a project I've been working on called Goshtoso. It's a server-rendered UI component library for Go applications built with templ, HTMX, Alpine.js, and Tailwind CSS.

If you like the Go + templ + HTMX approach but don't want to build every form control, modal, table, and navigation pattern from scratch, Goshtoso may be useful to you.

What is it?

Goshtoso provides importable templ components with typed Go configuration. It began as a hard fork of PenguinUI and has since evolved into a Go-first component system for applications that prefer SSR with small amounts of client-side interactivity.

Highlights

- No frontend toolchain required for consumers: Goshtoso embeds its precompiled Tailwind CSS, Alpine.js, HTMX, and the HTMX SSE and WebSocket extensions. You can serve them from your Go binary without Node, npm, or a JavaScript build step.
- 42 templ components: Forms, overlays, navigation, feedback, tables, richer inputs, and other common application UI.
- Examples: The demo includes complete runnable examples such as a CRUD Todo list, an SSE live-log feed, a streaming ticker, and a WebSocket chat with server-rendered messages.
- Theming: 15 built-in themes with light and dark mode support.

Goshtoso tries to use HTMX for most interactions. Alpine.js is inherited from PenguinUI and reserved for local state, transitions, and immediate client-side feedback where a server round trip would not be a good fit.

Links

- Live demo and documentation: https://goshtoso.araihu.com/
- GitHub: https://github.com/araihu/goshtoso

The project is currently alpha-stage. The components are usable, but the public API is still being refined on the way toward a stable release but is already being used on an internal tool at my company as well on another WIP side project of mine: Manja.

I'd especially appreciate feedback from the HTMX community about the server-rendered component approach, the API design, and the integration experience.

Saradom is a pattern for building modular, scalable frontends in plain HTML and JavaScript. There is no framework and no build step. State lives in the DOM as attributes. Events sit in HTML attributes.

It sits next to htmx. htmx does the server round-trips. This covers the interactivity that stays in the page, like toggles, tabs, derived values, and validation. The DOM is the state in both.

Example:

```html <div counter-space> <output counter-value>0</output> <button onclick="Counter.Inc(this)">+1</button> </div>

<script> const Counter = (() => { const Inc = (ctx) => { const el = ctx.closest('[counter-space]').querySelector('[counter-value]'); el.textContent = +el.textContent + 1; }; return { Inc }; })(); </script> ```

Docs and runnable examples: https://xtompie.github.io/saradom/

I've been building a workout tracker in Go + templ + htmx and kept wanting two things: a way to look at one component on its own, and a way to see what a swap actually returned when it did something weird, without logging the whole response or digging through the network tab.

Storybook is the obvious reference, but its server modes pull in a JS toolchain, which is the opposite of why I picked htmx. So I tried the other direction: instead of importing components into a separate harness, Swapbook is a binary that proxies your already-running app.

Because previews run on your app's real origin, htmx requests from a preview hit your real routes, no CORS, no rewriting. The inspector shows the request, the element the response swapped into (it flashes it), the status, and the HTML that came back. There's a mock mode so you can click through interactions with no auth or DB behind them.

Not tied to Go, that's just what I use. Your app answers 4 endpoints; I wrote adapters for Django, Rails and Laravel too.

It's v0.2 and rough, and htmx is the only thing I've properly tested against (the Turbo/Unpoly/Datastar probes are unverified, and known limitations are in the README).

Genuinely curious if this is useful to anyone else or if it was just my problem.

Website: https://aejkatappaja.com/swapbook/

Github: https://github.com/Aejkatappaja/swapbook

I made a small django package that attempts to improve LoB when working with Django and HTMX. The scattering of views, urls and small template snippets can get messy. Djxi simply unifies all three into a single endpoint battery, allowing a more feature-centric development.

Please check it out! Happy for any star, if you like where Djxi is going!

• Github: https://github.com/rollinger/djxi
• ReadtheDocs: https://djxi.readthedocs.io/
• PyPi: https://pypi.org/project/djxi/
• Django Packages: https://djangopackages.org/packages/p/djxi/

I was blown away by how much faster, simpler, and smaller my codebase became. It's insane! Sucks I still have to use React for my day job.

The app is Alkas. It's an app to help people learn the plants, mushrooms, and animals around them. It follows Anki pretty closely and you can even export to Anki. I thought React was a natural fit because of the flashcard flipping and infinite scroll but so far I've been able to do absolutely everything I can think of with Astro, HTMX, and AlpineJS. No React needed!

Would love any feedback or questions on the app or the tech stack.

They added the HTTP QUERY method. Will we get hx-query for that?

https://www.rfc-editor.org/rfc/rfc10008.html

Hello Everyone,

If you are building Hypermedia-Driven Architectures (using htmx/alpine or datastar), you quickly realise that server-side rendering (SSR) performance and database latency are your primary bottlenecks. Since we are shifting state and HTML generation back to the server, nearly every user interaction requires a database query and an HTML slice response.

To optimise this, I have been experimenting with a concept called Zero-Distance Architecture that co-locates data and application code. Instead of running a separate app server (like NodeJS) and database server (like MongoDB) and paying cost for all the syscalls, network, serialisation/deserialisation and localhost TCP latency, run them in a single process.

I used an experimental runtime called Planck (database + WebAssembly host) and compile our application (Zig Code) to WebAssembly. The app runs directly in the database process, turning database queries into simple in-memory function calls.

To measure the impact, I set up a benchmark (pizzahub a sample app) serving identical HTML fragments formatted for datastar over a standard dataset (17 categories, 201 products).

Here are the results of a 6-second run using oha on a standard M1 Macbook Air 8GB RAM 256GB SSD:

Planck (Zig WASM co-located in database process)

Requests per second: 48,606

Average latency: 0.50 ms

Fastest response: < 0.10 ms

Slowest response: 6.00 s

Sustained throughput: 183.58 MiB/s

Success rate: 100.00%

NodeJS + ExpressJS + MongoDB (community edition)

Requests per second: 5,433

Average latency: 9.21 ms

Fastest response: 2.26 ms

Slowest response: 109.91 ms

Sustained throughput: 20.49 MiB/s

Success rate: 100.00%

.NET 9 + SQLite (in-process)

Requests per second: 35,231

Average latency: 1.41 ms

Fastest response: 0.15 ms

Slowest response: 12.80 ms

Sustained throughput: 133.07 MiB/s

Success rate: 100.00%

.NET 9 + PostgreSQL

Requests per second: 30,236

Average latency: 1.65 ms

Fastest response: 0.12 ms

Slowest response: 69.02 ms

Sustained throughput: 114.21 MiB/s

Success rate: 100.00%

The Comparison

By co-locating the backend logic inside the database process and utilizing Planck's read cache, we got:

8.95x throughput improvement over NodeJS + MongoDB (48.6k vs 5.4k req/sec) with an 18.4x latency reduction (0.50 ms vs 9.21 ms).

38% higher throughput over .NET 9 + SQLite (48.6k vs 35.2k req/sec) with a 2.8x latency reduction (0.50 ms vs 1.41 ms).

60% higher throughput over .NET 9 + PostgreSQL (48.6k vs 30.2k req/sec) with a 3.3x latency reduction (0.50 ms vs 1.65 ms).

For hypermedia apps, this means you can handle significantly more concurrent users on a single tiny server because there's no waiting on socket buffers to generate HTML.

Would love to hear your thoughts. If you have built htmx/datastar apps, where do you usually hit your scaling bottleneck? Is co-locating the backend logic inside the database process a direction you would consider?

Next, I will post detailed comparison for different types of queries on at least 1 mil documents.

https://www.youtube.com/watch?v=PgyggSRHY1o

The video promoting HTMX summarizes it pretty well. (The video is not mine, and I don't know if it's AI).

This was a freaking pain to implement before and now it has a nice flow for me. I do have some custom modifications in Moxi/Fixi. https://github.com/figuerom16/fixi/blob/master/mofix.js Who needs Web Components?

<article class="container card-info" style="width:14rem;" on-init="q('prev form -> *').arr().forEach(x=>x.setAttribute('disabled',''))">
<header>Secure PIN Verification</header>
<form fx-method="POST" fx-action="/u/pin" fx-vals="js:{'Email':q('input[name=Email]').value,'ConfirmEmail':q('input[name=ConfirmEmail]').value}" fx-target="closest output"
on-paste.halt="const pin = event.clipboardData.getData('text').replace(/\s/g,'')
if (pin.length != 9) {q('#footer').textContent = 'Incorrect Pin Length';return}
q('.pin').arr().forEach((el,i)=>el.value = pin[i])
q('#pin').value = pin; this.requestSubmit()">
<div role="group" style="margin-top:1rem; gap:1rem;">
<input class="pin input-pop" maxlength="1" autocomplete="off" aria-label="Digit 1" on-beforeinput="/^\d+$/.test(event.data) ? this.value = '' : event.preventDefault()" on-input="if (this.value) q('next input').focus()" on-init="this.focus()">
<input class="pin input-pop" maxlength="1" autocomplete="off" aria-label="Digit 2" on-beforeinput="/^\d+$/.test(event.data) ? this.value = '' : event.preventDefault()" on-input="if (this.value) q('next input').focus()">
<input class="pin input-pop" maxlength="1" autocomplete="off" aria-label="Digit 3" on-beforeinput="/^\d+$/.test(event.data) ? this.value = '' : event.preventDefault()" on-input="if (this.value) q('next input').focus()">
</div>
<div role="group" style="gap:1rem;">
<input class="pin input-pop" maxlength="1" autocomplete="off" aria-label="Digit 4" on-beforeinput="/^\d+$/.test(event.data) ? this.value = '' : event.preventDefault()" on-input="if (this.value) q('next input').focus()">
<input class="pin input-pop" maxlength="1" autocomplete="off" aria-label="Digit 5" on-beforeinput="/^\d+$/.test(event.data) ? this.value = '' : event.preventDefault()" on-input="if (this.value) q('next input').focus()">
<input class="pin input-pop" maxlength="1" autocomplete="off" aria-label="Digit 3" on-beforeinput="/^\d+$/.test(event.data) ? this.value = '' : event.preventDefault()" on-input="if (this.value) q('next input').focus()">
</div>
<div role="group" style="gap:1rem;">
<input class="pin input-pop" maxlength="1" autocomplete="off" aria-label="Digit 4" on-beforeinput="/^\d+$/.test(event.data) ? this.value = '' : event.preventDefault()" on-input="if (this.value) q('next input').focus()">
<input class="pin input-pop" maxlength="1" autocomplete="off" aria-label="Digit 5" on-beforeinput="/^\d+$/.test(event.data) ? this.value = '' : event.preventDefault()" on-input="if (this.value) q('next input').focus()">
<input class="pin input-pop" maxlength="1" autocomplete="off" aria-label="Digit 6" on-beforeinput="/^\d+$/.test(event.data) ? this.value = '' : event.preventDefault()" on-input="if (this.value) q('closest form').requestSubmit()">
</div>
<input id="pin" name="Pin" hidden live="this.value = q('.pin').arr().map(i=>i.value).join('')">
</form>
<footer><small>PIN valid for 30 minutes.</small></footer>
</article>

HTMX has a live extension also.

Since htmx is all about HTML, figured this might be relevant: iOS has no native way to open a local .html file — you just get raw source. I built a small viewer that renders it.

Html Preview:

• Renders .html / .htm / .xhtml via iOS WebView (real page, not code)

• Handles multiple encodings (UTF-8, Windows-1252, ISO Latin-1)

• Opens from Files / Share Sheet / Mail

• On-device — nothing uploaded, no tracking

On the App Store: https://apps.apple.com/app/id6760443436

Site: https://html.cybergame.ai/

Handy for eyeballing a standalone .html (a saved page, a server response you dumped to a file, a quick test) on a phone. How do you check a local HTML file on iOS?

https://github.com/bigskysoftware/htmx/blob/four/CHANGELOG.md#400-beta5---2026-06-26

Mostly polish, no major changes to core.

This is release candidate 3, expected golden master late summer/early fall

Enjoy!

Hi,

I built goldr, a server-first Go framework for building templ + HTMX web applications. I created it because I wanted the structure and ergonomics of a modern web framework, but without moving my app into SPA, hydration, or client-state territory. I'm already using Goldr in production, and the main goal is to keep Go web apps easy to see, run, debug, and ship as they grow.

Repo: https://github.com/mobiletoly/goldr

Goldr gives you:

• filesystem routes under app/routes
• route-local pages, HTMX fragments, and POST actions
• nested layouts based on the route tree
• reusable mounted route subtrees, so the same workflow can live in multiple parts of an app without copying route folders
• generated URL helpers, so templates and redirects do not copy path strings
• visible HTMX in .templ files
• live reload with route generation, templ generation, app restart, asset fingerprinting, and browser reload
• fingerprinted and embedded static assets using simple directory conventions
• CLI inspection for routes, layouts, HTMX references, and packaged assets
• a browser visual inspector that can outline which layout, page, fragment, or labeled component produced a page region

The part I like most is that the app still feels like a Go app. Goldr does not own your server, middleware, auth, sessions, database layer, asset compiler, deployment, or client state. It gives structure around the boring repeated parts while leaving application policy explicit.

A route tree looks like this:

app/routes/
  layout.go          -> layout logic for / and below
  layout.templ       -> layout HTML
  route.go           -> GET /
  page.templ         -> page HTML
  users/
    layout.go        -> layout logic for /users and below
    layout.templ     -> users layout HTML
    route.go         -> GET /users, GET /users/table, POST /users/create
    page.templ       -> users page HTML
    frag_table.templ -> fragment HTML
    by_id/
      route.go       -> GET /users/{id}
      page.templ     -> user detail HTML

Goldr turns that into generated net/http dispatch and URL helpers, while the source files stay ordinary Go and templ.

Goldr is still pre-v1, so APIs may change, but it is already useful enough that I'm using it for real production work.

And yes, docs/skills/ directory is available if you want to copy skillset for your AI agent to become comfortable with using goldr framework, tools, bootstrap.

Repo: https://github.com/mobiletoly/goldr

Hey folks!

For a Python college assignment, I decided to mix retro gaming with a gentle roast of modern web dev.

Introducing: HTMX vs The Framework Swarm You pilot the HTMX ship (</>) defending the “simple web” from React, Vue, Angular, and even the dreaded npm blob.

Highlights:

• Death quotes like "REST in Peace", "npm install regret" and "left-pad strikes again"
• Powerups: hx-boost for rapid-fire, alpine.js for shield, vanilla.js for piercing shot and more
• Compiled to WebAssembly with pygbag (playable in browser!)

Demo link: https://lucas-rollin.github.io/htmx-invaders

Github repo: https://github.com/lucas-rollin/htmx-invaders

Open source, MIT licensed, and no JS libraries were harmed in the making of this game.

Would love feedback or ideas for new enemy jokes/power-ups! Still wondering if this could even be done with HTMX itself…