5 ms·

How I use HTMX with Go

315 points by gnabgib 3mo ago

typesafeJ 3mo ago
[dead]
xp84 3mo ago
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.
- wasmperson 3mo ago
  > 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.
- masfoobar 3mo ago
  100%
nzoschke 3mo ago
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 https://housecat.com/blog/the-gus-stack-go-unix-sqlite [2] https://exe.dev/docs/guts https://exe.dev/docs/guts
- nzoschke 3mo ago
  Could rebrand to the HUGS stack -- HTMX (or hypertext), Unix, Go, SQLite
  - didip 3mo ago
    I love HUGS a lot too. Currently building a next gen platform using strictly HUGS.
  - 0xDEFACED 3mo ago
    my vote is for GUSH
  - osigurdson 3mo ago
    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.
    - rob74 3mo ago
      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?
      - ColonelPhantom 3mo ago
        Or HOGS? HTMX-OS-Go-Sqlite. While having "OS" in there is kind of redundant, it does make for a nice and general acronym.
      - tapotatonumber9 3mo ago
        GASH?
        3mo ago
androiddrew 3mo ago
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
- bbg2401 3mo ago
  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.
_superposition_ 3mo ago
Nice post. Gotta love the GOTH stack
- defrost 3mo ago
  There's no other tool for extracting wasps from stings in flight.
  - _superposition_ 3mo ago
    And they claim naming things is hard...
pbjerkeseth 3mo ago
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://get.convictional.com/
- nchmy 3mo ago
  https://data-star.dev 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.
  - JSR_FDED 3mo ago
    Can confirm
  - pbjerkeseth 3mo ago
    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.
- dzonga 3mo ago
  dope app.
sethops1 3mo ago
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: return htmx.Write(w, &htmx.Template{ FS: htmx.FS(ui.HTMX, "parts"), Filename: "arrows.html", Fields: []any{thread, up}, }, &htmx.Component{ HTML: ` <div {{$count := index . 0 -}} {{- $thread := index . 1 -}} hx-swap-oob=true id="points-{{$thread}}" class="points">{{$count}} points</div>`, Fields: []any{count, thread}, }, ) [1] https://github.com/cattlecloud/webtools/tree/main/htmx https://github.com/cattlecloud/webtools/tree/main/htmx
- deleted 3mo ago
  [deleted]
smallerfish 3mo ago
I wrote a framework for my own use that uses Kotlin + HTMX - https://github.com/reubenfirmin/zoned 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.
artooro 3mo ago
Go + Datastar is simpler, I much prefer it.
- lazypenguin 3mo ago
  I also prefer Datastar but the new features coming in HTMX4 closes the gap more. Happy to see the ecosystem converging on good patterns.
  - nchmy 3mo ago
    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.
    - lenkite 3mo ago
      I would just go all the way to using https://unpoly.com/ https://unpoly.com/ if I wanted the full-bang whiz.
    - yawaramin 3mo ago
      Last I checked Datastar doesn't support progressive enhancement. I like using <a href hx-boost=true> and <form method action hx-boost=true> so almost all my functionality works even without JavaScript. See https://dev.to/yawaramin/why-hx-boost-is-actually-the-most-important-feature-of-htmx-3nc0 https://dev.to/yawaramin/why-hx-boost-is-actually-the-most-i...
      - nchmy 3mo ago
        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.
overflowy 3mo ago
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 https://github.com/mantinedev/vite-min-template
- yawaramin 3mo ago
  What's an example of a UI that you built with Mantine that you couldn't with htmx?
  - fhn 3mo ago
    they never said "couldn't". they said "feels like the complexity"
    - yawaramin 3mo ago
      Ok, what’s an example of the complexity growing at 2:1 rate with htmx but not with Mantine?
      - overflowy 3mo ago
        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).
        3mo ago
arjie 3mo ago
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.
neeraga 3mo ago
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.
phreack 3mo ago
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.
- yawaramin 3mo ago
  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.
latent22 3mo ago
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.
chenster 3mo ago
Every time I see a post on Htmlx made to frontpage, it gives me utter joy.
yawaramin 3mo ago
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 https://github.com/WebReflection/uhtml-ssr If it’s a Go backend then a library like https://www.gomponents.com/ 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.
- mb2100 3mo ago
  Agreed, but uhtml-ssr looks a bit dated. If you want a html tagged template literal lib with no dependencies, see for example: implementation: https://github.com/mastrojs/mastro/blob/main/src/core/html.ts https://github.com/mastrojs/mastro/blob/main/src/core/html.t... docs: https://mastrojs.github.io/docs/html-components/ https://mastrojs.github.io/docs/html-components/
- andypants 3mo ago
  You can also use jsx on the backend. React has renderToStaticMarkup, but you probably want to use one of the jsx libraries written specifically for the backend.
  - yawaramin 3mo ago
    You can use JSX but tagged template literals are supported out of the box by JS runtimes, so you wouldn’t need to add a build step.
- outlandishCat 3mo ago
syngrog66 3mo ago
This is one of the stories I wonder how it made the HN front page. Whether an upvote ring or clicks-for-hire service used.
- alexedwards 3mo ago
  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.
  - gnabgib 3mo ago
    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 https://github.com/zserge/lorca [1]: https://wails.io/ https://wails.io/
ai_fry_ur_brain 3mo ago
[dead]
foxwell_1959 3mo ago
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?
arch1e 3mo ago
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.
- mixmastamyk 3mo ago
  The htmx site is clear about tradeoffs and that it is not suitable for that use case. Though you have to dig for the articles.
- designerarvid 3mo ago
  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.
  - intrasight 3mo ago
    Yes. And additionally most "apps" are just static web sites with static components.
  - pepperoni_pizza 3mo ago
    I think it very much depends on what you're doing. Would it make sense to build Google Docs in HTMX? Probably not. Does it make sense to roll out SPA + JSON API for something that is basically a reskinned Django Admin? Probably not.
- solatic 3mo ago
flaie 3mo ago
Currently 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.
localhostinger 3mo ago
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.
- akazantsev 3mo ago
  > 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.
  - alexedwards 3mo ago
    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.
- tg180 3mo ago
fmind-dev 3mo ago
I'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.
mmusc 3mo ago
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.
Zababa 3mo ago
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.
- yawaramin 3mo ago
  See https://news.ycombinator.com/item?id=48915935 https://news.ycombinator.com/item?id=48915935
pjmlp 3mo ago
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.
hasanhaja 3mo ago
In a similar vein, I've been really enjoying the Go + Datastar combo with Templ.
franchb 3mo ago
[flagged]
auraham 3mo ago
I've been learning about React, Vue, and HTMX these days. As I understand, these tools aim to bring some level of interaction in a web application: - Both React and Vue are all about reactivity: you have a variable, make it reactive by using something like ref() or useEffect(), and the framework will patch the DOM whenever that reactive variable changes. The idea is easy to understand but hard to implement. I agree with this podcast [1], where the author mentions that writing good React code is hard. I like Vue, but it is a bit overwhelming since it has many functions for creating reactive variables, like ref(), refs(), isRef(), unRef(), reactive(), toRefs(), computed(), etc [2]. - HTMX follows a similar idea: patching the DOM when an event occurs. Unlike React and Vue, HTMX does not rely on reactivity. Instead, it uses attributes like hx-get for requesting HTML fragments to the backend, patching the UI using those fragments. No watchers, no reactivity, just plain requests. This is (to some extend) suitable for dashboards, pagination, sorting tables, autocompletion. But if your application requires a higher level of interactivity, then React and Vue are a better option [2]. Then we have LiveView and Elixir, which I think is a better alternative/trade-off to these three tools: - Similarly to React and Vue, LiveView has reactive variables (called assigns, you can think of it as a hashmap that holds the state of your application): every time the assigns changes, LiveView reloads the corresponding HTML fragment. This operation is efficient because LiveView knows which parts of the HTML fragment are static and which parts are dynamic. So when some variable changes, LiveView sends a tiny payload to the UI for updating the DOM. - Also, LiveView follows an arguably simpler approach for reactivity, you only need to implement three functions: mount() to setup the initial state of the assigns, render() to prepare the HTML content, and handle_event() to handle events like button clicks or form submissions. I think LiveView is so much easier to follow: if the assigns change, then the framework will update all the relevant HTML fragments. That's it. Also, we do not need to worry about adding third-party libraries for routing, state management, forms. Those are likely included in Phoenix. [1] https://www.youtube.com/live/pMwTR2KeuaU?si=AU7sqxVwTv4lRhV6&t=1288 https://www.youtube.com/live/pMwTR2KeuaU?si=AU7sqxVwTv4lRhV6... [2] https://youtu.be/k1TrnzZaygo?si=kCpMvOgB0Egk5mDg&t=380 https://youtu.be/k1TrnzZaygo?si=kCpMvOgB0Egk5mDg&t=380
Oxodao 3mo ago
The videos do not work under Firefox (on windows at least), probably codec related but unfortunate
codiku 3mo ago
Why doesn't htmx became ultra popular among devs ?
- asdfsa32 3mo ago
  Because it is good for a very narrow scope of things, once you go beyond that, it becomes a kludge to work with. People hate on React but it is the product of 2 decades of various experiments. It is popular because it really works.
  - sgt 3mo ago
    Been building a fairly medium to large sized web app in HTMX these last few months and if done correctly, it can be done fairly cleanly and it's best combined with templates of some kind (e.g. the templating in Golang or in Django).
    - evilduck 3mo ago
      “If done correctly” applies to about everything though.
      - sgt 3mo ago
        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.
        asdfsa32 3mo ago
        I see you're a true Go programmer. "You're holding it wrong".
xutopia 3mo ago
For the life of me I can't comprehend how people today start new projects and default to using React. Rails Hotwire, Phoenix Liveview, HTMX are all vastly faster and easier to maintain. I keep hearing people say that if you want a really complex UI you need React but to those people I answer with 2 points. 1) Most of these people don't realize that if a component on the page is so complex you probably have usability issues. 2) React doesn't need to control the entirety of the page. You can contain your complex React components within a web page.
- deleted 3mo ago
  [deleted]
PrimalPower 3mo ago
Am I the only one who dislikes Go specifically for CRUD webapps? I’ve worked with Go professionally for the past 5 years, and I genuinely like the language. I like the anti-framework philosophy, the simplicity, the resistance to over-abstraction or even worse... bad abstractions, fast builds, the light native binaries, and how easy it is for a team to converge on idiomatic code. But the moment you’re building a normal product app, even “basic CRUD” is rarely just CRUD. You need a database layer, migrations, auth, validation, maybe an OpenAPI spec, background jobs, admin flows, maybe server-side rendering, maybe GraphQL, etc. You can end up with a large codebase full of repetitive boilerplate for an app that does not actually do much conceptually. Maybe some people see a large codebase and feel accomplished, but just because each line of code is readable doesn't mean you know what its doing.

315 points by gnabgib 3mo ago

[dead]

xp84 3mo ago

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.

wasmperson 3mo ago
> 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.
masfoobar 3mo ago
100%

nzoschke 3mo ago

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 https://housecat.com/blog/the-gus-stack-go-unix-sqlite [2] https://exe.dev/docs/guts https://exe.dev/docs/guts

nzoschke 3mo ago
Could rebrand to the HUGS stack -- HTMX (or hypertext), Unix, Go, SQLite
- didip 3mo ago
  I love HUGS a lot too. Currently building a next gen platform using strictly HUGS.
- 0xDEFACED 3mo ago
  my vote is for GUSH
- osigurdson 3mo ago
  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.
  - rob74 3mo ago
    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?
    - ColonelPhantom 3mo ago
      Or HOGS? HTMX-OS-Go-Sqlite. While having "OS" in there is kind of redundant, it does make for a nice and general acronym.
    - tapotatonumber9 3mo ago
      GASH?
      - 3mo ago

androiddrew 3mo ago

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

bbg2401 3mo ago
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.

_superposition_ 3mo ago

Nice post. Gotta love the GOTH stack

defrost 3mo ago
There's no other tool for extracting wasps from stings in flight.
- _superposition_ 3mo ago
  And they claim naming things is hard...

pbjerkeseth 3mo ago

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://get.convictional.com/

nchmy 3mo ago
https://data-star.dev 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.
- JSR_FDED 3mo ago
  Can confirm
- pbjerkeseth 3mo ago
  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.
dzonga 3mo ago
dope app.

sethops1 3mo ago

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: return htmx.Write(w, &htmx.Template{ FS: htmx.FS(ui.HTMX, "parts"), Filename: "arrows.html", Fields: []any{thread, up}, }, &htmx.Component{ HTML: ` <div {{$count := index . 0 -}} {{- $thread := index . 1 -}} hx-swap-oob=true id="points-{{$thread}}" class="points">{{$count}} points</div>`, Fields: []any{count, thread}, }, ) [1] https://github.com/cattlecloud/webtools/tree/main/htmx https://github.com/cattlecloud/webtools/tree/main/htmx

deleted 3mo ago
[deleted]

smallerfish 3mo ago

I wrote a framework for my own use that uses Kotlin + HTMX - https://github.com/reubenfirmin/zoned 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.

artooro 3mo ago

Go + Datastar is simpler, I much prefer it.

lazypenguin 3mo ago
I also prefer Datastar but the new features coming in HTMX4 closes the gap more. Happy to see the ecosystem converging on good patterns.
- nchmy 3mo ago
  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.
  - lenkite 3mo ago
    I would just go all the way to using https://unpoly.com/ https://unpoly.com/ if I wanted the full-bang whiz.
  - yawaramin 3mo ago
    Last I checked Datastar doesn't support progressive enhancement. I like using <a href hx-boost=true> and <form method action hx-boost=true> so almost all my functionality works even without JavaScript. See https://dev.to/yawaramin/why-hx-boost-is-actually-the-most-important-feature-of-htmx-3nc0 https://dev.to/yawaramin/why-hx-boost-is-actually-the-most-i...
    - nchmy 3mo ago
      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.

overflowy 3mo ago

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 https://github.com/mantinedev/vite-min-template

yawaramin 3mo ago
What's an example of a UI that you built with Mantine that you couldn't with htmx?
- fhn 3mo ago
  they never said "couldn't". they said "feels like the complexity"
  - yawaramin 3mo ago
    Ok, what’s an example of the complexity growing at 2:1 rate with htmx but not with Mantine?
    - overflowy 3mo ago
      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).
      - 3mo ago

arjie 3mo ago

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.

neeraga 3mo ago

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.

phreack 3mo ago

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.

yawaramin 3mo ago
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.

latent22 3mo ago

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.

chenster 3mo ago

Every time I see a post on Htmlx made to frontpage, it gives me utter joy.

yawaramin 3mo ago

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 https://github.com/WebReflection/uhtml-ssr If it’s a Go backend then a library like https://www.gomponents.com/ 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.

mb2100 3mo ago
Agreed, but uhtml-ssr looks a bit dated. If you want a html tagged template literal lib with no dependencies, see for example: implementation: https://github.com/mastrojs/mastro/blob/main/src/core/html.ts https://github.com/mastrojs/mastro/blob/main/src/core/html.t... docs: https://mastrojs.github.io/docs/html-components/ https://mastrojs.github.io/docs/html-components/
andypants 3mo ago
You can also use jsx on the backend. React has renderToStaticMarkup, but you probably want to use one of the jsx libraries written specifically for the backend.
- yawaramin 3mo ago
  You can use JSX but tagged template literals are supported out of the box by JS runtimes, so you wouldn’t need to add a build step.
outlandishCat 3mo ago

syngrog66 3mo ago

This is one of the stories I wonder how it made the HN front page. Whether an upvote ring or clicks-for-hire service used.

alexedwards 3mo ago
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.
- gnabgib 3mo ago
  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 https://github.com/zserge/lorca [1]: https://wails.io/ https://wails.io/

ai_fry_ur_brain 3mo ago

[dead]

foxwell_1959 3mo ago

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?

arch1e 3mo ago

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.

mixmastamyk 3mo ago
The htmx site is clear about tradeoffs and that it is not suitable for that use case. Though you have to dig for the articles.
designerarvid 3mo ago
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.
- intrasight 3mo ago
  Yes. And additionally most "apps" are just static web sites with static components.
- pepperoni_pizza 3mo ago
  I think it very much depends on what you're doing. Would it make sense to build Google Docs in HTMX? Probably not. Does it make sense to roll out SPA + JSON API for something that is basically a reskinned Django Admin? Probably not.
solatic 3mo ago

flaie 3mo ago

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

localhostinger 3mo ago

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.

akazantsev 3mo ago
> 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.
- alexedwards 3mo ago
  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.
tg180 3mo ago

fmind-dev 3mo ago

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

mmusc 3mo ago

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.

Zababa 3mo ago

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.

yawaramin 3mo ago
See https://news.ycombinator.com/item?id=48915935 https://news.ycombinator.com/item?id=48915935

pjmlp 3mo ago

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.

hasanhaja 3mo ago

In a similar vein, I've been really enjoying the Go + Datastar combo with Templ.

franchb 3mo ago

[flagged]

auraham 3mo ago

I've been learning about React, Vue, and HTMX these days. As I understand, these tools aim to bring some level of interaction in a web application: - Both React and Vue are all about reactivity: you have a variable, make it reactive by using something like ref() or useEffect(), and the framework will patch the DOM whenever that reactive variable changes. The idea is easy to understand but hard to implement. I agree with this podcast [1], where the author mentions that writing good React code is hard. I like Vue, but it is a bit overwhelming since it has many functions for creating reactive variables, like ref(), refs(), isRef(), unRef(), reactive(), toRefs(), computed(), etc [2]. - HTMX follows a similar idea: patching the DOM when an event occurs. Unlike React and Vue, HTMX does not rely on reactivity. Instead, it uses attributes like hx-get for requesting HTML fragments to the backend, patching the UI using those fragments. No watchers, no reactivity, just plain requests. This is (to some extend) suitable for dashboards, pagination, sorting tables, autocompletion. But if your application requires a higher level of interactivity, then React and Vue are a better option [2]. Then we have LiveView and Elixir, which I think is a better alternative/trade-off to these three tools: - Similarly to React and Vue, LiveView has reactive variables (called assigns, you can think of it as a hashmap that holds the state of your application): every time the assigns changes, LiveView reloads the corresponding HTML fragment. This operation is efficient because LiveView knows which parts of the HTML fragment are static and which parts are dynamic. So when some variable changes, LiveView sends a tiny payload to the UI for updating the DOM. - Also, LiveView follows an arguably simpler approach for reactivity, you only need to implement three functions: mount() to setup the initial state of the assigns, render() to prepare the HTML content, and handle_event() to handle events like button clicks or form submissions. I think LiveView is so much easier to follow: if the assigns change, then the framework will update all the relevant HTML fragments. That's it. Also, we do not need to worry about adding third-party libraries for routing, state management, forms. Those are likely included in Phoenix. [1] https://www.youtube.com/live/pMwTR2KeuaU?si=AU7sqxVwTv4lRhV6&t=1288 https://www.youtube.com/live/pMwTR2KeuaU?si=AU7sqxVwTv4lRhV6... [2] https://youtu.be/k1TrnzZaygo?si=kCpMvOgB0Egk5mDg&t=380 https://youtu.be/k1TrnzZaygo?si=kCpMvOgB0Egk5mDg&t=380

Oxodao 3mo ago

The videos do not work under Firefox (on windows at least), probably codec related but unfortunate

codiku 3mo ago

Why doesn't htmx became ultra popular among devs ?

asdfsa32 3mo ago
Because it is good for a very narrow scope of things, once you go beyond that, it becomes a kludge to work with. People hate on React but it is the product of 2 decades of various experiments. It is popular because it really works.
- sgt 3mo ago
  Been building a fairly medium to large sized web app in HTMX these last few months and if done correctly, it can be done fairly cleanly and it's best combined with templates of some kind (e.g. the templating in Golang or in Django).
  - evilduck 3mo ago
    “If done correctly” applies to about everything though.
    - sgt 3mo ago
      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.
      - asdfsa32 3mo ago
        I see you're a true Go programmer. "You're holding it wrong".

xutopia 3mo ago

For the life of me I can't comprehend how people today start new projects and default to using React. Rails Hotwire, Phoenix Liveview, HTMX are all vastly faster and easier to maintain. I keep hearing people say that if you want a really complex UI you need React but to those people I answer with 2 points. 1) Most of these people don't realize that if a component on the page is so complex you probably have usability issues. 2) React doesn't need to control the entirety of the page. You can contain your complex React components within a web page.

deleted 3mo ago
[deleted]

PrimalPower 3mo ago

Am I the only one who dislikes Go specifically for CRUD webapps? I’ve worked with Go professionally for the past 5 years, and I genuinely like the language. I like the anti-framework philosophy, the simplicity, the resistance to over-abstraction or even worse... bad abstractions, fast builds, the light native binaries, and how easy it is for a team to converge on idiomatic code. But the moment you’re building a normal product app, even “basic CRUD” is rarely just CRUD. You need a database layer, migrations, auth, validation, maybe an OpenAPI spec, background jobs, admin flows, maybe server-side rendering, maybe GraphQL, etc. You can end up with a large codebase full of repetitive boilerplate for an app that does not actually do much conceptually. Maybe some people see a large codebase and feel accomplished, but just because each line of code is readable doesn't mean you know what its doing.