How I use HTMX with Go

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

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.

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.

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.

I'm feel inspired to convert some old stuff to HTMX

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.

I did the first 90% by hand, and have done the last 10% (and README) with Claude, just to get it out there.

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

[1] https://get.convictional.com/

  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},
    },

  )

These are all existing common pain points that the new version allows us to address.

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.

Back and forth the pendulum goes.

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.

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

[2] https://youtu.be/k1TrnzZaygo?si=kCpMvOgB0Egk5mDg&t=380

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.