If you’re using htmx, I highly recommend an HTML generation technique in your backend that lets you easily componentize in the same way as you can with React. Eg, extracting common pieces of HTML markup into functions much like React components.
The reason is that htmx requires a certain amount of flexibility in the HTML generated by the backend. Eg, you need to be able to generate a certain piece of HTML markup and put a <title> tag immediately adjacent to it in some situations, and not in others. (Htmx updates the page title when it finds a <title> tag at the top level.)
This kind of flexibility is difficult with traditional string-based templating engines, but trivial with language-embedded HTML libraries.
If it’s Scala then ScalaTags. And so on, you get the picture. The point is that a language-embedded system allows you to use the full power of your language to build abstractions and components, which htmx really benefits from.
Love Go + HTMX. I pair it with a-h/templ for a bit more type safety on the template, components and partials.
I just shared my whole toolkit too [1], I call it the "GUS stack" -- Go, Unix, SQLite. Inspired heavily by the exe.dev "GUTS" stack [2] but with HTMX instead of Typescript.
Some other Go components in the kit...
- cockroachdb/errors for errors with stack traces
- templ for type-safe HTML templates (with htmx for reactivity and tailwindcss for CSS)
- fuego for an OpenAPI spec generated from web handlers
- sqlc for type-safe code generated from SQL
- modernc.org/sqlite for a pure Go sqlite library
- goose for SQL and Go migrations
- dbos for durable workflows in SQLite
- rod for Chrome / CDP testing and automation
Feels so productive coding, agentic coding, and building and deploying binaries with this stack.
I have seen this as the GoTH stack, Go Templ Htmx. Add sqlc to that gor GoTHs or GHosT stack.
Love this combo, once you buy into "go generate ./..." as a build step you get so much.
I also add goverter for converting between sqlc models and template objects and return values. Like 50% of the boilerplate is generated and it makes type safety so nice
I tried to use templ but it felt more frustrating than ergonomic. Like at that point I'd rather just use react (and I hate react). Just sticking with basic std templates + HTMX sprinkling is good enough for my needs.
I used HTMX on a recent project and really enjoyed it. As a person who knows how the Web worked before the invention of AngularJS and React, I deeply appreciate being able to build actual pages and minimize the amount of JS that has to exist. Vanilla JS works fine, but HTMX basically just substitutes for a lot of boilerplate that you'd otherwise have to create just to do the same event handler stuff over and over.
If you're curious, and you too aren't in love with the "Modern frontend" philosophy, I would recommend trying out HTMX. Of note, the first examples of HTMX on the HTMX site are really basic, but it's much more powerful with a bit more learning.
> If you're curious, and you too aren't in love with the "Modern frontend" philosophy
I'm also going to hesitantly mention sveltekit. From the outside it looks like yet another JS front-end framework but having been forced to use it recently I've learned it actually has great support for the more hypertext-focused design philosophy promoted by HTMX and friends.
I wrote a framework for my own use that uses Kotlin + HTMX - https://github.com/reubenfirmin/zoned. The goal was to see if I could create webapps that were fully typed, end to end. It uses Kotlinx.html, which provides a jsx-ish dsl for writing html.
I did the first 90% by hand, and have done the last 10% (and README) with Claude, just to get it out there.
Seconded on the Alex Edwards adoration. Anyone with the slightest interest in learning Go for web development should pick up both Let's Go and Let's Go Further. They are two of the most approachable, enjoyable and practical introductions to a programming language I've read.
While I love both Go and Alex, my experience with HTMX has always ended up being disappointing.
I think the best way to put it, when I'm working with HTMX it feels like the complexity of the codebase is growing at a 2:1 rate compared to the app itself. I always end up with some weird edge case that I can not come out of without some weird hack.
I get why people dislike Node packages, HTMX feels like it's an overcompensating response to that. But the time you save by not having to wrestle with JSON is tripled when you try to make the app actually look or feel good. It takes me 2 minutes to slap together a Mantine template [1] and tap into some of the best UI components, then I can embed the built static assets and end up with the same single Go binary.
I've found that my whole design philosophy has to change to work with HTMX. That's not a dig, it may even be a good thing, but it's a significant shift. The designs become much more native to the web and much less inspired by mobile apps.
Huge fan of HTMX. Agent can reason about components well. Iteration is good and testing story is solid. Very happy with results. I use Rust/Go (prefer Go - safer package ecosystem - no build time code running) with HTMX.
We use this[1] little package, which enables chaining together HTMX responses that can be based on an HTML template file, an HTML raw string, or plain text. All but the first being OOB targets. Real example:
I've always wondered, is there a way to visually preview the partials and whole pages? I'm used to modern niceties such as hot reload with Tailwind that I'd like to have with HTMX, which I'm looking for excuses to try.
I typically just write them as plain old HTML files while I develop them. Then once I like the look and feel of a component or page I just convert it into a template. And Visual Studio Code’s HTML Preview extension has a hot reload feature, it works perfectly.
But the point is that Datastar only exists because htmx rejected all of those ideas. Now it's becoming a cheap, more complex, less powerful, heavier copy of Datastar. Just use the genuine article.
there is a Additional HTMX configuration section and it is interesting that all 4 issues here have now been resolved by default in htmx4. History cache is now not included by default and you have to opt in to the new improved history extension. Attribute inheritance is now off by default and has a much better implicit inherit design. Indicator styles are no longer a manual injected style tag and now use constructable style sheets feature which is much cleaner and CSP safe. and default timeout is no 60s.
These are all existing common pain points that the new version allows us to address.
HTMX is excellent. We made it a long way at Convictional[1] with HTMX + AlpineJS, but the eventual transition of our product into lots of live collaborative surfaces had us feeling like we had pushed the envelope as far as we could under modern startup constraints. Unfortunately, frontier models have really hurt development with budding tech that doesn't have the training data presence of things like React.
https://data-star.dev is what you were yearning for, friend. It is more powerful, faster and smaller than htmx and alpine combined, and has all sorts of capabilities specifically for multi-player live reactivity.
If you’re using htmx, I highly recommend an HTML generation technique in your backend that lets you easily componentize in the same way as you can with React. Eg, extracting common pieces of HTML markup into functions much like React components.
The reason is that htmx requires a certain amount of flexibility in the HTML generated by the backend. Eg, you need to be able to generate a certain piece of HTML markup and put a <title> tag immediately adjacent to it in some situations, and not in others. (Htmx updates the page title when it finds a <title> tag at the top level.)
This kind of flexibility is difficult with traditional string-based templating engines, but trivial with language-embedded HTML libraries.
Eg, if your backend is in JS then a tagged template literal function like https://github.com/WebReflection/uhtml-ssr
If it’s a Go backend then a library like https://www.gomponents.com/
If it’s Scala then ScalaTags. And so on, you get the picture. The point is that a language-embedded system allows you to use the full power of your language to build abstractions and components, which htmx really benefits from.
Love Go + HTMX. I pair it with a-h/templ for a bit more type safety on the template, components and partials.
I just shared my whole toolkit too [1], I call it the "GUS stack" -- Go, Unix, SQLite. Inspired heavily by the exe.dev "GUTS" stack [2] but with HTMX instead of Typescript.
Some other Go components in the kit...
- cockroachdb/errors for errors with stack traces
- templ for type-safe HTML templates (with htmx for reactivity and tailwindcss for CSS)
- fuego for an OpenAPI spec generated from web handlers
- sqlc for type-safe code generated from SQL
- modernc.org/sqlite for a pure Go sqlite library
- goose for SQL and Go migrations
- dbos for durable workflows in SQLite
- rod for Chrome / CDP testing and automation
Feels so productive coding, agentic coding, and building and deploying binaries with this stack.
[1] https://housecat.com/blog/the-gus-stack-go-unix-sqlite
[2] https://exe.dev/docs/guts
I have seen this as the GoTH stack, Go Templ Htmx. Add sqlc to that gor GoTHs or GHosT stack. Love this combo, once you buy into "go generate ./..." as a build step you get so much.
I also add goverter for converting between sqlc models and template objects and return values. Like 50% of the boilerplate is generated and it makes type safety so nice
Could rebrand to the HUGS stack -- HTMX (or hypertext), Unix, Go, SQLite
my vote is for GUSH
I love HUGS a lot too. Currently building a next gen platform using strictly HUGS.
I tried to use templ but it felt more frustrating than ergonomic. Like at that point I'd rather just use react (and I hate react). Just sticking with basic std templates + HTMX sprinkling is good enough for my needs.
I used HTMX on a recent project and really enjoyed it. As a person who knows how the Web worked before the invention of AngularJS and React, I deeply appreciate being able to build actual pages and minimize the amount of JS that has to exist. Vanilla JS works fine, but HTMX basically just substitutes for a lot of boilerplate that you'd otherwise have to create just to do the same event handler stuff over and over.
If you're curious, and you too aren't in love with the "Modern frontend" philosophy, I would recommend trying out HTMX. Of note, the first examples of HTMX on the HTMX site are really basic, but it's much more powerful with a bit more learning.
> If you're curious, and you too aren't in love with the "Modern frontend" philosophy
I'm also going to hesitantly mention sveltekit. From the outside it looks like yet another JS front-end framework but having been forced to use it recently I've learned it actually has great support for the more hypertext-focused design philosophy promoted by HTMX and friends.
I wrote a framework for my own use that uses Kotlin + HTMX - https://github.com/reubenfirmin/zoned. The goal was to see if I could create webapps that were fully typed, end to end. It uses Kotlinx.html, which provides a jsx-ish dsl for writing html.
I did the first 90% by hand, and have done the last 10% (and README) with Claude, just to get it out there.
I love Alex Edwards. His books and Learn go with tests were my first introduction to the language. Still recommend to this day.
I'm feel inspired to convert some old stuff to HTMX
Seconded on the Alex Edwards adoration. Anyone with the slightest interest in learning Go for web development should pick up both Let's Go and Let's Go Further. They are two of the most approachable, enjoyable and practical introductions to a programming language I've read.
I'm using HTMX with the Bun stack and somehow it is working great for us.
We are working on building an app builder that uses HTMX as an frontend technology, along with SQLite for the database and Bun for the backend.
While I love both Go and Alex, my experience with HTMX has always ended up being disappointing.
I think the best way to put it, when I'm working with HTMX it feels like the complexity of the codebase is growing at a 2:1 rate compared to the app itself. I always end up with some weird edge case that I can not come out of without some weird hack.
I get why people dislike Node packages, HTMX feels like it's an overcompensating response to that. But the time you save by not having to wrestle with JSON is tripled when you try to make the app actually look or feel good. It takes me 2 minutes to slap together a Mantine template [1] and tap into some of the best UI components, then I can embed the built static assets and end up with the same single Go binary.
[1] https://github.com/mantinedev/vite-min-template
I've found that my whole design philosophy has to change to work with HTMX. That's not a dig, it may even be a good thing, but it's a significant shift. The designs become much more native to the web and much less inspired by mobile apps.
What's an example of a UI that you built with Mantine that you couldn't with htmx?
they never said "couldn't". they said "feels like the complexity"
Ok, what’s an example of the complexity growing at 2:1 rate with htmx but not with Mantine?
Huge fan of HTMX. Agent can reason about components well. Iteration is good and testing story is solid. Very happy with results. I use Rust/Go (prefer Go - safer package ecosystem - no build time code running) with HTMX.
We use this[1] little package, which enables chaining together HTMX responses that can be based on an HTML template file, an HTML raw string, or plain text. All but the first being OOB targets. Real example:
[1] https://github.com/cattlecloud/webtools/tree/main/htmxI've always wondered, is there a way to visually preview the partials and whole pages? I'm used to modern niceties such as hot reload with Tailwind that I'd like to have with HTMX, which I'm looking for excuses to try.
I typically just write them as plain old HTML files while I develop them. Then once I like the look and feel of a component or page I just convert it into a template. And Visual Studio Code’s HTML Preview extension has a hot reload feature, it works perfectly.
Go + Datastar is simpler, I much prefer it.
I also prefer Datastar but the new features coming in HTMX4 closes the gap more. Happy to see the ecosystem converging on good patterns.
But the point is that Datastar only exists because htmx rejected all of those ideas. Now it's becoming a cheap, more complex, less powerful, heavier copy of Datastar. Just use the genuine article.
there is a Additional HTMX configuration section and it is interesting that all 4 issues here have now been resolved by default in htmx4. History cache is now not included by default and you have to opt in to the new improved history extension. Attribute inheritance is now off by default and has a much better implicit inherit design. Indicator styles are no longer a manual injected style tag and now use constructable style sheets feature which is much cleaner and CSP safe. and default timeout is no 60s.
These are all existing common pain points that the new version allows us to address.
HTMX is excellent. We made it a long way at Convictional[1] with HTMX + AlpineJS, but the eventual transition of our product into lots of live collaborative surfaces had us feeling like we had pushed the envelope as far as we could under modern startup constraints. Unfortunately, frontier models have really hurt development with budding tech that doesn't have the training data presence of things like React.
[1] https://get.convictional.com/
https://data-star.dev is what you were yearning for, friend. It is more powerful, faster and smaller than htmx and alpine combined, and has all sorts of capabilities specifically for multi-player live reactivity.
Can confirm
Nice post. Gotta love the GOTH stack
There's no other tool for extracting wasps from stings in flight.
And they claim naming things is hard...
Every time I see a post on Htmlx made to frontpage, it gives me utter joy.