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.
How I use HTMX with Go
111–120 of 121 posts
Re: How I use HTMX with Go
#112Earlier quoted context omitted.
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.
Last I checked Datastar doesn't support progressive enhancement. I like using and so almost all my functionality works even without JavaScript. See https://dev.to/yawaramin/why-hx-boost-is-actually-the-most-i...
Re: How I use HTMX with Go
#113Love 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
Oh my GOSH (GoSqliteHtmx) stack.
Re: How I use HTMX with Go
#114Earlier quoted context omitted.
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.
Last I checked Datastar doesn't support progressive enhancement. I like using and so almost all my functionality works even without JavaScript. See https://dev.to/yawaramin/why-hx-boost-is-actually-the-most-i...
Its not evident to me that that is really a concern when datastar is so small, and most of the js is written inline.
Moreover, htmx can only do a fraction of what datastar does - you'd need to add on something like alpinejs to be able to try to fill the gaps. Both combined are much larger than datastar, and not nearly as integrated.
Re: How I use HTMX with Go
#115Earlier quoted context omitted.
“If done correctly” applies to about everything though.
Problem is that a lot of people don't want to spend some minimum effort getting some fundamental understanding about the technology they are using. They just want to rush it to build something. It's been like that forever.
I see you're a true Go programmer. "You're holding it wrong".
Re: How I use HTMX with Go
#116Earlier quoted context omitted.
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?
Back in the days of the LAMP stack, the use of Linux would have been much less obvious and thus warranted the inclusion of the "L" in the acronym. After all, leaving it out might arguably have sounded better - the AMP stack.
Re: How I use HTMX with Go
#117HTMX 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…
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.
Discovered data-star a little around that time, maybe a little after HTMX. I'll probably dabble with personal projects, but no stomach for the business to try something in that vein again. "Nobody ever got fired for picking ~SAP~ React" and all that.
Re: How I use HTMX with Go
#118This 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 a…
I just liked the content.. I can't answer the rest of the speculation ¯\_(ツ)_/¯
Have you tried Lorca[0]? A wails that assumes you have chrome installed (as most do) so: much smaller binaries.
[0]: https://github.com/zserge/lorca
[1]: https://wails.io/
Re: How I use HTMX with Go
#119As 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…
With HTMX 4.0 it might be a bit nicer. I use my own home-grown HTMZ-BE lib/snippet that has the back end decide where to place the elements. Deciding from the back end makes it so you go from a lot of eventing on the front end to middleware on the back end, which significantly reduces the complexity of the application. And then when you do have a lot of interactivity you just send down the whole interactive area and have morphdom (HTMX uses idiomorph, I believe) which will do a comparison of the DOM compared to what your new HTML is and update just what needs to be updated.
I've found that to really reduce the complexity of my applications. If I really do need something more powerful with state machine interaction, then I use VanJS. But, really, I've only used that for my static sites where I need a little interaction on the front end and no back end connection.
Here's an example of using HTMZ-BE (which can easily be extended to HTMX 4.0 and Data-Star - if you need even more features).
https://github.com/jon49/Soccer
It also uses an _ attribute pattern on the HTML for simple, declarative front end state interaction. Makes the user's life a little nicer.
It's amazing how simple things can be if you work with it and think about, "I want simplicity." A lot of the front end frameworks add a lot of complexity, even nice frameworks like Svelte, I think because the paradigm is just wrong.
Re: How I use HTMX with Go
#120Love 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…
On the other end of things, for tiny responsive web apps that don't necessarily even need their own built in database, like e.g. real time API dashboards, I've been using my PAHG template a lot lately [1]. Pico.css, Alpine.js, Htmx, Go. There's no reason one couldn't hook this up to SQLite, of course. [1] https://github.com/hiAndrewQuinn/pahg-template
you might want to try Blades CSS also, a fully compatible and actively maintained successor to Pico CSS (which was last updated >1 ago)