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.
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'm unfamiliar with these stacks but including "U" / Unix seems odd. I suspect these run completely fine on Linux, Windows or macOS. Its almost like including an "E" in your stack for electricity.
Well, the good old LAMP stack (Linux-Apache-MySQL-PHP - this was the first of these acronyms as far as I'm aware of) included L for Linux so it would make a nicer acronym. Some people changed it to WAMP when running under Windows. But HWGS doesn't roll off the tongue nicely. Maybe HAGS (with "Apple" standing in for MacOS) would work?
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 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
Lately I'm really liking jet[1] for typesafe SQL. It requires a live DB to generate the code, but I see that as a positive as well, since you are forced to apply migrations before writing code.
Huge fan of jet. It lets you just write SQL, but in your Go. I basically can’t imagine using anything else now.
Why is that better than writing plain SQL like in sqlc? My main reason was being able to dynamically construct queries and reuse different bits. Plain SQL statements simply don’t compose at all, and I don’t recall sqlc giving any solution to help with this.
I'm bit sad that hyperscript[1] doesn't get the love it deserves when discussing HTMX.
Hyperscript fits perfectly in the Go + HTMX stack to do DOM manipulation without having to make a server round trip or having to write a separate JS function.
I get that not many are fan of such declarative programming, but when there's already HTML file we're working with; Hyperscript feels just like an extension of it.
I have been working on a Open Payment Host[2] which handles multiple payment gateways and was able to perform complex DOM manipulation with just Hyperscript.
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.
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.
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 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.
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.
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.
Basically any data grid that implements multiple AND/OR filters at column level, sorting, reordering, infinite scrolling, virtualization for handling large amounts of data, etc. Also handling basic pending / error / retry states (things that I take for granted with React Query).
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.
I understand the sentiment. Rails was my introduction to hypermedia and it was convenient and easy, so experiencing friction when building with Go/HTMX came as a surprise.
After a few attempts I learned that abstractions are important :D
Without a component builder and reversible router is indeed pretty painful (and Rails just ships with these things so you didn't have to worry about it).
The biggest benefit for me personally is that computation and data live in one place, which carries you very far. Also, machines like hypermedia: LLMs are great at using and testing hypermedia apps because they are self-contained and the cycle time is lower because you don't need to wait for JS.
And yes, no easy off the shelf component library makes starting harder.
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.
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.
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.
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.
As the author of this post, I can answer this question with a very clear "no".
There is an interesting side point though. I've been blogging about Go since 2013 (generally writing similar articles to this one) and from 2013 to 2025 I think just one post made the front page of HN. In 2026, all 3 posts I've written have.
My theory is that there's now fewer people spending the time to write original content. With LLMs and AI-generated instant answers in search, the incentive to write these kind of deep-dive articles is way less than it used to be, so maybe there's both less competition and more appreciation for it? That's my working theory at the moment anyway.
I love the combination of Go and HTMX, but these types of articles usually only show the basics. Coming from a JavaScript frontend NPM ecosystem heavy background, I would love to see a write up for a production ready application. Show how you handle asset bundling and hashing. What are the best DX tools for running the local dev server with hot reloading. How do you manage the few JS libraries dependencies that you need. Do you still include a Node package manager or are you using CDN’s?
As someone who tried to build a fairly large project with HTMX + Go, I can say it just wasn't there for me. Maybe it will get there eventually, but I'm not convinced.
For simple CRUD apps and admin dashboards, HTMX is great. But once you have lots of interconnected components, shared state, and complex interactions, managing everything quickly becomes difficult.
I originally chose HTMX because I really didn't enjoy working with React. Eventually I tried SvelteKit, and it completely changed my perspective. I still use Go for the backend, but SvelteKit in SPA mode for the frontend. It gives me a clean separation between the two while making complex UIs much easier to build and maintain.
What really sold me was that Svelte feels like a natural extension of HTML rather than a different language with JSX. State management is simple, the component model is intuitive, and the new `$state` syntax is especially nice.
Isn’t the whole point of HTMX philosophy to question whether you need interconnected components with shared state? Most apps are doing crud on a database at the end of the day.
HTMX is great for a lot of things, but if you're working in a team, and your colleagues are not on board, it's tough. Lots of "this is not a serious technology" kind of arguments. All kinds of bugs simply initially blamed on the choice of using HTMX. Even if proven wrong afterwards, the damage is already done. And this was in the most excellent team I have worked in so far.
I'm happy that I got to experience this and I learned from it. Gotta choose your battles or something.
As for Go's html/template: I think it has one of the weirdest / most unnatural interfaces. I recently reread "A Philosophy of Software Design" and one of its key points is to keep interfaces simple and push complexity downwards, making it easier for others to use. Now why do I have to care about "cloning templates" every time I render some html template? Love the Go stdlib, but this thing feels unnecessary complex to me.
> Now why do I have to care about "cloning templates" every time I render some html template?
You do not have to. It's a self-sustained injury by the author. You can compile the templates once and just execute them.
The issue is that author wants to specify page titles in the main templates. If you pass titles as a context, you can split base.tmpl into BASE_BEGIN, BASE_END and use them in the final templates.
Yes, you will have to pass the title depending on the page template during the But his tactics will break anyway when you try to support different languages.
That's not the reason I use Clone() in this pattern. The main reason for the clone operation is convenience. The clone operation is on the already-parsed set of shared templates (base+partials in this example code). It provides the convenience of not having to specify the path to the base template and any paths to the partial templates needed by that page in the call to render().
There may also be a performance benefit too - I suspect that the Clone() operation is cheaper than re-parsing the base and any necessary partial templates in each render() call, but I've never benchmarked it, so I can't assert that with certainty.
As much as I really like htmx -- this is a sad truth!
I tried to pitch htmx to my team last year and found an opportunity to create a simple webapp. One of the devs really struggled with htmx after years of muscle memory returning json and rendering in JS/JQuery. It was a lot of "I now have to do this.. how do I solve this problem?"
I think he would have struggled with any different approach whether we changed to angular, react, etc. htmx didn't really stand a chance.
The other dev, on the other hand, didn't even bother to try it.
All I heard from the team was Blazor this, blazor that.
Personally I think it's a shame. We are a small team and would be good to avoid javascript 95% of the time. We could just generate server side code/html which, imo, would create organised code base. Easy to test as well.
Any personal web projects I still use htmx and reached a decent flow with it. Completely simplifies web dev, imo.
I'm in an advisor position, and I tried very hard to mentor the team, explaining that learning this technology deepens your understanding of the browser. Whereas React etc isolates you from the actual environment you're working in - the browser.
On html/template, I like the security by default, and obviously it's built-in. But the dynamicness leaves too many open-ended questions unanswered. Templ is great, but the ergonomics leaves many things to be desired. After writing a few large production applications in it. I decided to create gsx: https://github.com/gsxhq/gsx
I've tried to like Go with HTMX, but the big issue was always Go templates. I feel like if there was something like JSX/TSX but for Go, it would be a way better dev experience, but right now it's mostly a pain. Templ tries to go in that direction, but a year or so ago editor integration and tooling weren't great.
71 comments
[ 4.0 ms ] story [ 45.9 ms ] threadIf 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.
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 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 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
[1] https://github.com/go-jet/jet
Why is that better than writing plain SQL like in sqlc? My main reason was being able to dynamically construct queries and reuse different bits. Plain SQL statements simply don’t compose at all, and I don’t recall sqlc giving any solution to help with this.
Hyperscript fits perfectly in the Go + HTMX stack to do DOM manipulation without having to make a server round trip or having to write a separate JS function.
I get that not many are fan of such declarative programming, but when there's already HTML file we're working with; Hyperscript feels just like an extension of it.
I have been working on a Open Payment Host[2] which handles multiple payment gateways and was able to perform complex DOM manipulation with just Hyperscript.
[1] https://hyperscript.org/
[2] https://openpaymenthost.com/
I'm feel inspired to convert some old stuff to HTMX
[1] https://get.convictional.com/
I did the first 90% by hand, and have done the last 10% (and README) with Claude, just to get it out there.
Off-course these additional tools are not free [2].
[1] Rocket for WebComponents, Stellar for CSS
[2] Nothing wrong in charging but $349 is a tad too expensive for me. I will happily pay if it was in double digits.
I would add a-h/templ for templates and it has Datastar support as well.
It is staggering how Datastar is not more popular.
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
After a few attempts I learned that abstractions are important :D
Without a component builder and reversible router is indeed pretty painful (and Rails just ships with these things so you didn't have to worry about it).
The biggest benefit for me personally is that computation and data live in one place, which carries you very far. Also, machines like hypermedia: LLMs are great at using and testing hypermedia apps because they are self-contained and the cycle time is lower because you don't need to wait for JS.
And yes, no easy off the shelf component library makes starting harder.
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.
These are all existing common pain points that the new version allows us to address.
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.
implementation: https://github.com/mastrojs/mastro/blob/main/src/core/html.t...
docs: https://mastrojs.github.io/docs/html-components/
There is an interesting side point though. I've been blogging about Go since 2013 (generally writing similar articles to this one) and from 2013 to 2025 I think just one post made the front page of HN. In 2026, all 3 posts I've written have.
My theory is that there's now fewer people spending the time to write original content. With LLMs and AI-generated instant answers in search, the incentive to write these kind of deep-dive articles is way less than it used to be, so maybe there's both less competition and more appreciation for it? That's my working theory at the moment anyway.
For simple CRUD apps and admin dashboards, HTMX is great. But once you have lots of interconnected components, shared state, and complex interactions, managing everything quickly becomes difficult.
I originally chose HTMX because I really didn't enjoy working with React. Eventually I tried SvelteKit, and it completely changed my perspective. I still use Go for the backend, but SvelteKit in SPA mode for the frontend. It gives me a clean separation between the two while making complex UIs much easier to build and maintain.
What really sold me was that Svelte feels like a natural extension of HTML rather than a different language with JSX. State management is simple, the component model is intuitive, and the new `$state` syntax is especially nice.
Opus and GPT are very good at it, it's fast to build and start, convenient to deploy and host, one binary. I like it very much.
Very good stack to iterate fast.
I'm happy that I got to experience this and I learned from it. Gotta choose your battles or something.
As for Go's html/template: I think it has one of the weirdest / most unnatural interfaces. I recently reread "A Philosophy of Software Design" and one of its key points is to keep interfaces simple and push complexity downwards, making it easier for others to use. Now why do I have to care about "cloning templates" every time I render some html template? Love the Go stdlib, but this thing feels unnecessary complex to me.
You do not have to. It's a self-sustained injury by the author. You can compile the templates once and just execute them.
The issue is that author wants to specify page titles in the main templates. If you pass titles as a context, you can split base.tmpl into BASE_BEGIN, BASE_END and use them in the final templates.
Yes, you will have to pass the title depending on the page template during the But his tactics will break anyway when you try to support different languages.
There may also be a performance benefit too - I suspect that the Clone() operation is cheaper than re-parsing the base and any necessary partial templates in each render() call, but I've never benchmarked it, so I can't assert that with certainty.
I tried to pitch htmx to my team last year and found an opportunity to create a simple webapp. One of the devs really struggled with htmx after years of muscle memory returning json and rendering in JS/JQuery. It was a lot of "I now have to do this.. how do I solve this problem?"
I think he would have struggled with any different approach whether we changed to angular, react, etc. htmx didn't really stand a chance.
The other dev, on the other hand, didn't even bother to try it.
All I heard from the team was Blazor this, blazor that.
Personally I think it's a shame. We are a small team and would be good to avoid javascript 95% of the time. We could just generate server side code/html which, imo, would create organised code base. Easy to test as well.
Any personal web projects I still use htmx and reached a decent flow with it. Completely simplifies web dev, imo.
I'm in an advisor position, and I tried very hard to mentor the team, explaining that learning this technology deepens your understanding of the browser. Whereas React etc isolates you from the actual environment you're working in - the browser.
On html/template, I like the security by default, and obviously it's built-in. But the dynamicness leaves too many open-ended questions unanswered. Templ is great, but the ergonomics leaves many things to be desired. After writing a few large production applications in it. I decided to create gsx: https://github.com/gsxhq/gsx