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?
How I use HTMX with Go
41–50 of 121 posts
Re: How I use HTMX with Go
#42We 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: return htmx.Write(w, &htmx.Template{ FS: htmx.FS(ui.HTMX, "parts"), Filename: "arrows.html", Fields: []any{thread, up}, }, &htmx.Component{ HTML: ` {{$count}} points `, Fields: []any{count, thread}, }, ) [1] http…
[deleted]
Re: How I use HTMX with Go
#43As 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.
Re: How I use HTMX with Go
#44While 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 overcompe…
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.
Re: How I use HTMX with Go
#45Love 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…
Could rebrand to the HUGS stack -- HTMX (or hypertext), Unix, Go, SQLite
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.
Re: How I use HTMX with Go
#46Currently almost all of my side projects, LLM assisted or not, are coded in Go + HTMX.
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.
Re: How I use HTMX with Go
#47HTMX 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.
Re: How I use HTMX with Go
#48This is one of the stories I wonder how it made the HN front page. Whether an upvote ring or clicks-for-hire service used.
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.
Re: How I use HTMX with Go
#49I've switched from Python to Go + HTMX recently. It's a really nice combo, fast, efficient, and easy to maintain. HTMX should be part of the HTML spec.
Re: How I use HTMX with Go
#50While 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 overcompe…
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 p…
I’m struggling myself a bit with the components and routers in HTMX/go. Can you recommend any source code or reading on that topic?