HN Explorer

37 comments

[ 3.3 ms ] story [ 111 ms ] thread
xp84
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.

nzoschke
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

[2] https://exe.dev/docs/guts

androiddrew
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

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

sethops1
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
smallerfish
I wrote a framework for my own use that uses Kotlin + HTMX - 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
Go + Datastar is simpler, I much prefer it.
overflowy
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

arjie
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
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
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.
latent22
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
Every time I see a post on Htmlx made to frontpage, it gives me utter joy.
yawaramin
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

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.

syngrog66
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.
foxwell_1959
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
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
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.
nymanjon
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 _<action> 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.

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

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