Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- For those wondering, here's how you can join me, the CEO of HTMX, as CEO of HTMX: https://htmx.ceo/by hmokiguess
- I found Htmx to be a great combo with agent driven development. It lets you end-to-end test the UI without a full headless browser by just examing the HTML, which means UI tests are cheap and fast, which means you can have tons of them. And coding agents are exactly as good as your test coverage. So with Htmx they're great.
- You found HTMX?by rwoerz
- Well, if someone is going to vibe code they don't have enough background on searching a good tool. They'll just ask LLM and LLM defaults to a Javascript based thing
- A thoughtful, clean, and useful library that wasn't built to climb the corporate ladder. It grew organically. I think it became a cry of relief for those annoyed by unnecessary complexity, which also boosted its recognition. It served as a starting point for things like Datastar, too. I believe it brought a refreshing breath of air to the frontend landscape.
- As CEO of HTMX, I am very proud of the work achieved by the team.by Baguette5242
- > Like it or not, a lot of people are using LLMs and we are providing the following skills files for
For what? Don't leave us hanging!
by GrayShade - As fellow CEO of HTMX, I approve of this statement and concur. I think our next major moves will be to monetize our assets [0].by all2
- Before vibe coding was a thing, HTMX made it super easy for me to implement Ajax like features. It was the most approachable library I've ever seen, and I'll always be grateful for it.by havaloc
- What about vibe coding makes HTMX something that you speak about in the past tense? Are you just generating frontends in vanilla JS now?
- As the CEO of HTMX, I've never used HTMX but I've been keeping an eye on the releases, essays, and talks. Congratulations to the team.by miguel-muniz
- Most sites/apps I work on are progressively enhanced (https://www.gov.uk/service-manual/technology/using-progressi...)
So far I've used a little bit of htmx (2) for one of them, and I really love it. Just a few attributes and we get some very reasonable progressively enhanced client/server interactive elements without full page loads.
Not sure I would choose if I had to make a SPA - it's partially from ignorance, but right not not sure how to avoid spaghetti. But I think it makes me even more strongly consider _not_ making a SPA
by michalc - TIL! One more reason to like gov.uk. I had no idea this was a standard but in hindsight it's quite obvious that's the case. I wonder how much of a burden it is at times, and how one can enforce this with automation?by duxuev
- > `hx-alpine-compat` - smooths over compatibility issues between htmx and Alpine.js
I looked into this when I tried HTMX 4 on a project earlier this year. I actually found that https://alpine-ajax.js.org/ was smaller than HTMX while providing all the features I needed. It is one of the sanctioned projects they link to so I felt good using it
by james2doyle - great library, we link to it on our alternatives page
- Somewhat of an aside: it's ironic the that some of the clearest, most concise technical documentation I now find on the Internet has come out that way because it was written for a machine: https://raw.githubusercontent.com/bigskysoftware/htmx/v4.0.0...
Human readers don't receive this level of care or attention.
by hliyan - It's removing all the unnecessary words and fluff. FWIW I adhere to RFC-2119 when writing docs, and tell agents to do so as well.by DrBazza
- It took me a long time to grok what htmx even was from barely glancing at news articles about it every once in a while. If I'd seen such a concise text explanation I'm sure I'd have got it immediately! Lesson learned: go to LLM docs first I guess?by phreack
- I had a similar thought when someone linked [1] Mike Acton's "Data-Oriented Design Operating Rules" [2] written for agents. The text is Claude-y, but the step-by-step DOD guidance is neat, it specifies a development protocol the likes of which I haven't seen elsewhere, besides in Mike's talks (in less detail).
1. https://news.ycombinator.com/item?id=49062520
2. https://github.com/macton/nagent/blob/main/context/data-orie...
by Rendello - Maybe a contrarian view, but as someone very knowledgeable about .NET API backends + angular on the frontend, I've found that HTMX made things more difficult as it required me to move back to mixing presentation concerns with business-logic and data concerns (basically have the backend produce the UI, which is whole point of HTMX).
This is not a criticism but I suspect that the people enjoying HTMX are either people preferring old-school server-side rendering or react users.
Just sharing my experience, because HTMX is the absolute darling of hacker news.
Since i mainly develop real SPA, i found that is more complex than just using typscrpit if you build something non-trivial as managing state on the server is not fun at all.
In my opinion if you are happy using angular, you'll find that HTMX is a step backward in terms for dev experience. Can't speak about react, but since it is not a battery included stack unlike Angular, i can understand why many people find they'd be better off moving things server-side instead of messing around with 15 third-party libraries. My 2 cents
by rednb - I totally agree. When we started splitting presentation from content (CSS) that was a wonderful step forwards. And splitting back-end and front-end concerns similarly makes for a cleaner and more elegant design in both codebases.
IMO HTMX is a weird regression in our design patterns. Hopefully a temporary anomaly. I'd never choose to work in a company that adopted this mixing of front and back end code - it's a red flag as far as I'm concerned.
by cbeach - I'll shill datastar for a second, there's barely a notion of frontend state management if you treat HTML as a projection surface with interactivity. I'd argue HTML is the most efficient wire format for interactive web apps, especially with streaming + compression.
Seriously DB->json->client->toHtml
DB->toHtml->client
Just imagine if that html wire format also conveyed the interactivity too and you eliminate the issues. And you can always seperate whatever concerns you want in whatever tpl lang of your choice.
Also htmx 4 is kinda just an worse datastar funnily enough In it's own way.
by fatplexer - > managing state on the server is not fun at all.
Really? I've never found that difficult. Sessions exist, URL parameters exist... Perhaps in a complex SPA you can have trouble, but so many of the "applications" I've worked on are just glorified documents.
by xp84 - There are an army of people using SPAs for problems best served by a simple and more traditional website. It has been a thing since SPAs started showing up so you have a whole generation who think that Next.js is just how you build for the web.
Then HTMX is to them what the micro-ORMs were for me (and, if you've been in .Net for a couple of decades, I suspect you too).
by radicalbyte - I agree this is a scope or focus thing. Different tools for different things.
If you are already maintaining a tool chain, a supply chain and skills in an SPA framework for multiple customer-facing, client-driven projects, I don't think you have much of a use for HTMX. Hence why at work, we have our full-time frontend engineers doing this, because it gives you the most flashy quality.
I am an infrastructure engineer. I have privately tried out a couple of SPA frameworks, The complexity to set this up for the first time is immense. And if you have rarely touched projects, the churn of the tooling and dependency ecosystem is taking up a significant amount of time for something that may be nice to have at work, or a pet project at home.
It's not cool if you have half a day to touch an old project and everything has rotted away around it so nothing interesting gets done. Something like Pydantic, Flask or Django + Jinja generally doesn't do that. And HTMX can make it nicer fairly cheaply.
by tetha - > ... managing state on the server is not fun at all.
Do you not have a database for your backend? Managing state is kind of their thing.
by aidenn0 - I don't understand (possibly because I lack Angular experience): what is it about a .NET backend using HTMX that requires presentation concerns to be mixed with business logic?
Don't you have to maintain that separation either way? Your core/application logic shouldn't know how its result is ultimately represented. That could be JSON or HTML over HTTP, Protobuf over a TCP stream, or a custom binary protocol over a Unix socket.
Obviously those representations matter at the presentation/transport boundary, but why should choosing HTML force that concern into the business logic?
by splawn - I agree. We are moving away from HTMX at work, to React. (After we moved away from Angular. That was…a choice…that I didn’t make.)
Here’s the thing: there’s still a place for HTMX. Lots of places. But “building an SPA but not actually and SPA” is not a lane for HTMX. Nor do they promote HTMX for that purpose. Really quite the opposite.
Different tools for different jobs. (Me? I honestly love React, just a more minimal stack. Zustand and TanStack and Vite. No Redux or Next.JS)
by perardi - Congrats and thanks! htmx brings me joy.
Pretty much every experiment I build now starts with Go, htmx, and SQLite to keep things simple and fast but still responsive.
I put a few more thoughts about this here:
https://housecat.com/blog/the-hugs-stack-hypermedia-unix-go-...
by nzoschke - How are you using dbos with SQLite? The docs say its a Postgres libraryby bbkane