In fact, I find Django and Postgres to be the best solution for htmx but Go stack is probably almost as good in terms of developer velocity and obviously much faster. So I think that's a good solution.
You can really build powerful production apps with htmx, and what people underestimate is how good it is with AI assisted development (Claude understands it and does it well, and if any JS glue logic on a specific template is required, it's pretty well written and not a mess).
Django + Postgres on the backend plus a frontend of HTMX + alpine.js for a light touch of interactivity where needed is a killer combination. Claude is very good at it, and with the right instructions actually keeps things concise and modular without spilling into spaghettification. I would recommend this as a first option to anyone looking to spin up a new web stack if you’re not absolutely sure you need the heavyweight of React.
> `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
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.
I've always been a fan and supporter of HTMX, but lately I've wondered how beneficial it is now that LLMs can generate JavaScript for us. HTMX was especially useful when I wrote JavaScript by hand because I appreciated its higher level of abstraction and simplicity. I also struggled to make it work with AlpineJS and eventually had to resort to plain JavaScript, which gave me finer control. Normally, switching to JavaScript would have been a hassle but since an LLM can produce it as easily as any other text, I’m less clear on HTMX’s advantage. I’ve been getting along fine without it. If computers didn’t write code for us, I would still choose HTMX, but now I find it hard to justify the trade‑off.
There's definitely something to this: I expect LLMs to hurt the adoption of htmx and most smaller web libraries. That's fine: it's always been a labor of love and is BSD 0, so I hope the ideas are interesting and that the people who decide to use it enjoy it.
I think, at least for the next few years, certain preferences and consensuses were accidentally embedded in the models to your benefit.
They love htmx! Claude will independently suggest using it instead of more general js frameworks for smaller projects. A gpt model told me, and I wrote this down because it was striking, "htmx won the argument it was making."
It's the same thing with rust. I'm an ocaml expert and ocaml genuinely fits a lot of the problems I work with better regardless of that. But because of when the models were trained and what they were trained on, a certain sort of alt-consensus opinion is frozen into them, and it believes rust is a better choice for nearly everything!
I think you're good for the next few years at least. It's an open question what happens after that dead internet theory recursive loop of llms trained on llm output etc so who knows you might be good forever.
The last time I made a website about a year ago, Gemini used HTMX. It was actually my first experience with HTMX, so in a way, LLMs led to me adopting it. :D
It's hard to answer because I don't personally use HTMX as a way to avoid Javascript. HTMX is a Javascript library. And I don't know if I even find using HTMX easier/harder than writing JS, because they are fundamentally different approaches to building apps. It really just depends on what I'm trying to do.
One is a programming language used for writing client side code, and the other is a minimal library that makes server sent documents more ergonomic. Yes, it's a JS library with a few nice conveniences, but the main draw of HTMX encourages a completely different app architecture than what the average dev would arrive at with plain JS.
They're just two different things to me, and so it seems irrelevant if LLMs can help you write one faster. If you're only using HTMX to avoid JS, I don't see how LLMs discourage you from doing that. Wouldn't it be better to vibecode something you have an easier time reading than vibecode a language you don't even understand enough to use? What are you going to do if it blows up?
apologies, i thought you were saying you were switching to SPAs because LLMs understand it better. I see some version of that comment nearly daily now. Carry on!
I'm still skeptical of htmx being the foundation for a 100-year web service, but I think this is a really worthwhile goal. I'll add that aside from static HTML, I don't have a better option.
Thinking about how well your web architecture will hold up for 100 years (or even 10 years) is bikeshedding and a pointless exercise.
Perfect is the enemy of good and all that. If something is useful, it’s possible to fix the architecture later. The only counter-example I know of has been GitHub, which was built on RoR and so poorly planned that it’s still biting Microsoft on a regular basis.
Great library. Really enjoy using it. Agents work really well with the kind of site you build with it and it’s very easy to build. Thanks for the upgrade skills.
I'm not very familiar with htmx but at first glance it seems similar to Angular. I thought Angular lost favor because of all the extra attributes and boilerplate. What makes htmx different?
I'm glad I'm not using this. It's the opposite of how I like to build web apps (which is either SSR with tiny bits of JS on top that I like to use Alpine.js for; or a JS-app that I like to use Elm for as life is too short runtime errors).
Nonetheless I hope all who do use Htmx, enjoy using it.
I would classify HTMX as a different style of "SSR with tiny bits of JS on top." In fact, I would argue it is a more "pure" form of SSR-based interactive web development than an Alpine.js-style approach (I am not making any value judgment here).
As a joke. Back when 2 came out, they promised there would never be a version 3. I.e., no breaking changes. Then they realized they did need to make a breaking change, so the only way to be true to their promise was to skip version 3.
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-...
Agreed.
In fact, I find Django and Postgres to be the best solution for htmx but Go stack is probably almost as good in terms of developer velocity and obviously much faster. So I think that's a good solution.
You can really build powerful production apps with htmx, and what people underestimate is how good it is with AI assisted development (Claude understands it and does it well, and if any JS glue logic on a specific template is required, it's pretty well written and not a mess).
Django + Postgres on the backend plus a frontend of HTMX + alpine.js for a light touch of interactivity where needed is a killer combination. Claude is very good at it, and with the right instructions actually keeps things concise and modular without spilling into spaghettification. I would recommend this as a first option to anyone looking to spin up a new web stack if you’re not absolutely sure you need the heavyweight of React.
I call it the GOSH stack (Go Sqlite Htmx) but HUGS is good too.
Oh wow, interesting combo that I would never independently reach for, but thanks to your template I might have to give it a whirl!
> `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
great library, we link to it on our alternatives page
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.
As CEO of HTMX, I am very proud of the work achieved by the team.
> 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!
lol sorry about that, had a fix sitting in four-dev, merged to four and pushed, should be updated
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].
[0] https://www.youtube.com/watch?v=GyV_UG60dD4
I've always been a fan and supporter of HTMX, but lately I've wondered how beneficial it is now that LLMs can generate JavaScript for us. HTMX was especially useful when I wrote JavaScript by hand because I appreciated its higher level of abstraction and simplicity. I also struggled to make it work with AlpineJS and eventually had to resort to plain JavaScript, which gave me finer control. Normally, switching to JavaScript would have been a hassle but since an LLM can produce it as easily as any other text, I’m less clear on HTMX’s advantage. I’ve been getting along fine without it. If computers didn’t write code for us, I would still choose HTMX, but now I find it hard to justify the trade‑off.
There's definitely something to this: I expect LLMs to hurt the adoption of htmx and most smaller web libraries. That's fine: it's always been a labor of love and is BSD 0, so I hope the ideas are interesting and that the people who decide to use it enjoy it.
I think, at least for the next few years, certain preferences and consensuses were accidentally embedded in the models to your benefit.
They love htmx! Claude will independently suggest using it instead of more general js frameworks for smaller projects. A gpt model told me, and I wrote this down because it was striking, "htmx won the argument it was making."
It's the same thing with rust. I'm an ocaml expert and ocaml genuinely fits a lot of the problems I work with better regardless of that. But because of when the models were trained and what they were trained on, a certain sort of alt-consensus opinion is frozen into them, and it believes rust is a better choice for nearly everything!
I think you're good for the next few years at least. It's an open question what happens after that dead internet theory recursive loop of llms trained on llm output etc so who knows you might be good forever.
The last time I made a website about a year ago, Gemini used HTMX. It was actually my first experience with HTMX, so in a way, LLMs led to me adopting it. :D
It's hard to answer because I don't personally use HTMX as a way to avoid Javascript. HTMX is a Javascript library. And I don't know if I even find using HTMX easier/harder than writing JS, because they are fundamentally different approaches to building apps. It really just depends on what I'm trying to do.
One is a programming language used for writing client side code, and the other is a minimal library that makes server sent documents more ergonomic. Yes, it's a JS library with a few nice conveniences, but the main draw of HTMX encourages a completely different app architecture than what the average dev would arrive at with plain JS.
They're just two different things to me, and so it seems irrelevant if LLMs can help you write one faster. If you're only using HTMX to avoid JS, I don't see how LLMs discourage you from doing that. Wouldn't it be better to vibecode something you have an easier time reading than vibecode a language you don't even understand enough to use? What are you going to do if it blows up?
I mean, htmx and JS glue logic is truly the differentiator now because LLM's do it so well. It's absolutely the way to go.
the browser is and always will be built for dealing with SSR HTML
IMO current browsers are more like an operating system designed for progressive loading of apps.
That doesn't mean do dumb / complicated / bloated stuff for no reason. If the best thing for your users is static html, use that.
All apps I build are server-side rendered. I'm not sure how your comment changes the the question I'm asking.
apologies, i thought you were saying you were switching to SPAs because LLMs understand it better. I see some version of that comment nearly daily now. Carry on!
That's like rejecting video games because the CRT was built for displaying live TV streams sent over the public airwaves.
Oof bold claim
how so? that's what they do - incomparably faster than dealing with JS
Congratulations on the release!
I have enjoyed working with htmx very much.
I'm still skeptical of htmx being the foundation for a 100-year web service, but I think this is a really worthwhile goal. I'll add that aside from static HTML, I don't have a better option.
Thinking about how well your web architecture will hold up for 100 years (or even 10 years) is bikeshedding and a pointless exercise.
Perfect is the enemy of good and all that. If something is useful, it’s possible to fix the architecture later. The only counter-example I know of has been GitHub, which was built on RoR and so poorly planned that it’s still biting Microsoft on a regular basis.
Sure but it's a spectrum. Surely some choices will age much more poorly than others.
Is it just a coincidence that the image for this release is the same as for Omarchy Quattro? https://youtu.be/F7fe9pa8OeE
oh man that's embarassing, someone made that on twitter I didn't realize it was from omarchy, I've removed it, my bad
I think that's the joke
Great library. Really enjoy using it. Agents work really well with the kind of site you build with it and it’s very easy to build. Thanks for the upgrade skills.
I'm not very familiar with htmx but at first glance it seems similar to Angular. I thought Angular lost favor because of all the extra attributes and boilerplate. What makes htmx different?
htmx is based on the ideas of hypermedia, you can read the first chapter in our book on the topic here:
https://hypermedia.systems/hypermedia-a-reintroduction/
HTMX is a layer on top of server-side rendered HTML that gives you near-SPA-levels of interactivity without having to build a standalone SPA.
HTMX is a polar opposite to Angular in terms of complexity, for one.
I'm glad I'm not using this. It's the opposite of how I like to build web apps (which is either SSR with tiny bits of JS on top that I like to use Alpine.js for; or a JS-app that I like to use Elm for as life is too short runtime errors).
Nonetheless I hope all who do use Htmx, enjoy using it.
I would classify HTMX as a different style of "SSR with tiny bits of JS on top." In fact, I would argue it is a more "pure" form of SSR-based interactive web development than an Alpine.js-style approach (I am not making any value judgment here).
You can use ReScript with Htmx (or anything else) and get no runtime errors. It has a sound type system, great language.
Why did they skip version 3?
As a joke. Back when 2 came out, they promised there would never be a version 3. I.e., no breaking changes. Then they realized they did need to make a breaking change, so the only way to be true to their promise was to skip version 3.
Carson promised they'd never do a version 3...but he never said they couldn't do a version 4.
I'm so pumped for v8!
this guy gets it
The anchor links in the "on this page section" don't work for me (Android Firefox/Chrome).
> Note that attributes like hx-disinherit
Looks like some copy is missing here
Yep, fixed
> (plus at game)
Typo of "a"?
with enough eyes all typos are shallow (it was a long night)