How I use HTMX with Go • Hacker News Board

Re: How I use HTMX with Go

#51

Post by devnull3 » Wed, Jul 15, 2026, 7:08 AM UTC

lazypenguin wrote: post #20

artooro wrote: post #15

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.

Datastar has evolved into a suite of tools [1]. If anything the gap has widened.

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.

Re: How I use HTMX with Go

#52

Post by devnull3 » Wed, Jul 15, 2026, 7:10 AM UTC

artooro wrote: post #15

Go + Datastar is simpler, I much prefer it.

Yeah this combo fits as easily as a custom sized/fitted gloves would.

I would add a-h/templ for templates and it has Datastar support as well.

It is staggering how Datastar is not more popular.

Re: How I use HTMX with Go

#53

Post by designerarvid » Wed, Jul 15, 2026, 7:12 AM UTC

arch1e wrote: post #43

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 w…

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.

Re: How I use HTMX with Go

#54

Post by akazantsev » Wed, Jul 15, 2026, 7:14 AM UTC

localhostinger wrote: post #47

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…

> 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.

Re: How I use HTMX with Go

#55

Post by hellcow » Wed, Jul 15, 2026, 7:15 AM UTC

Abishek_Muthian wrote: post #39

nzoschke wrote: post #4

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…

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 bee…

There's security consequences to allowing inline JS, which hyperscript requires.

Re: How I use HTMX with Go

#56

Post by mmusc » Wed, Jul 15, 2026, 7:25 AM UTC

Another great combination is htmx and asp.net razor pages. You can build and reuse components with partials and keeps things super simple and clean.

Re: How I use HTMX with Go

#57

Post by rob74 » Wed, Jul 15, 2026, 7:47 AM UTC

osigurdson wrote: post #45

nzoschke wrote: post #11

Earlier quoted context omitted.

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.

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?

Re: How I use HTMX with Go

#58

Post by alexedwards » Wed, Jul 15, 2026, 7:53 AM UTC

akazantsev wrote: post #54

localhostinger wrote: post #47

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…

> 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, yo…

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.

Re: How I use HTMX with Go

#59

Post by Zababa » Wed, Jul 15, 2026, 8:19 AM UTC

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.

Re: How I use HTMX with Go

#60

Post by pjmlp » Wed, Jul 15, 2026, 8:27 AM UTC

The interesting part of HTMX is how we are back into classical server side rendering frameworks with Ajax updates.

Back and forth the pendulum goes.