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.
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).
> `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.
It's hard to answer because I don't personally find using HTMX as a way to avoid writing Javascript. HTMX is a Javascript library. And I don't know if I even find using it easier/harder than writing JS, because they are fundamentally different approaches to building apps.
One is a 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, but the effect HTMX has is a 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.
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.
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?
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.
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.
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.
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).
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
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
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
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.
It's hard to answer because I don't personally find using HTMX as a way to avoid writing Javascript. HTMX is a Javascript library. And I don't know if I even find using it easier/harder than writing JS, because they are fundamentally different approaches to building apps.
One is a 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, but the effect HTMX has is a 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.
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.
Oof bold claim
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.
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.
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.
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!
> 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)