I really like htmx, and intercooler.js before it. It's been a while since I tried to convince a co-worker to use it, it might be time to try again. Either way I can't wait to try out the new version.
Full Disclosure, I am CEO of HTMX
evbogue 2 minutes ago [-]
As a former CEO of HTMX I thank you for your service as the current CEO of HTMX.
jdlshore 10 hours ago [-]
Given the number of people claiming to be CEO of HTMX, I have to ask: what’s the joke I’m missing?
This is a social media presence worth striving for.
> You can put it on your LinkedIn, because it’s true.
I only take LinkedIn seriously under extreme protest, so this is extremely tempting.
ecshafer 9 hours ago [-]
One of the things that is great about htmx (besides being the best library) is the lack of modern silicon valley corpo communication. It has the slightly unhinged feel of a nerd that spent too much time on Newgrounds or 4chan or something awful. Which is how the internet aught to be.
testdelacc1 8 hours ago [-]
> unhinged
Please take a look at the official documentation for htmx, which specifically clarifies that the author owns many hinges.
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).
farmeroy 9 hours ago [-]
I had a great role for just over a year building with django/postgres/htmx! i ended up using lightweight web components for my js glue code (as well as shoelace, now web awesome, components). once a few patterns were established, claude code was extremely proficient. now getting back into frontend framework world i'm realizing what a lightweight, enjoyable experience that was...
Analemma_ 12 hours ago [-]
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.
WD-42 9 hours ago [-]
I use the same stack. Single codebase, no build step. It’s so refreshing.
michaelchisari 12 hours ago [-]
I call it the GOSH stack (Go Sqlite Htmx) but HUGS is good too.
Someone asked about using htmx with php on reddit, and was recommended a HAYW (Hypermedia on Anything You Want) stack.
trueno 3 hours ago [-]
i use this stack quite a bit too. i made the claude do some load bearing 360 backflips, gate and seam a whole buncha smoking guns, and bolt go-starlark on top of this so i can just declare little web apps like its streamlit but it doesn't feel sucky like streamlit. i get to just write little blurbs of python-looking code and i get these fully reactive tools. probably my favorite and most used abstraction that came from too much wine and lazy boredom. also built stupid simple framework ish coverage for connections and duckdb and a few other things.
ajayvk 3 hours ago [-]
Go backend with Starlark for dynamic behavior is a great combination. I have been building https://github.com/openrundev/openrun with that approach, mainly for teams to deploy internal tools. It can be used to deploy any containerized application. The management UI for OpenRun is built with the Hypermedia approach https://utils.demo.clace.io/console/
kaycebasques 13 hours ago [-]
Oh wow, interesting combo that I would never independently reach for, but thanks to your template I might have to give it a whirl!
dimaaan 10 hours ago [-]
If you want a prototype fast, don't you use an LLM?
And if you do, why start with a simpler framework?
shimman 11 hours ago [-]
I also like the same stack, as it plays very well with a terminal focus workflow.
rednb 8 hours ago [-]
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
perardi 7 hours ago [-]
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)
embedding-shape 6 hours ago [-]
Yeah, typically I end up building websites (for myself and others) in basically three "lanes". Static HTML/CSS files, great for docs, presentations, reports and similar. Or, websites with some interactive/dynamic elements, HTMX is great for this. Or, fully fledged "client-side apps" where it's more of an application than website, then I go full out dynamic programming with ClojureScript and similar approaches.
I'm not sure why so many people seemingly fall into the trap of trying to find one tool and then use that absolutely everywhere. I mean, I'm familiar with it as in "it's fun" as I used Nix as a framework for a static website builder, but I keep seeing people making those sort of choices professionally too. Like when React first became popular, then suddenly people try to jam it into absolutely everything, until they slowly walk back and then after some years agree that maybe it's good for some things, not for everything and not as a default.
perardi 4 hours ago [-]
Ha, that was me and Hugo, back in the day, for static sites.
And, yeah, HTMX is truly great for sites with limited interactivity. You really, really do not want or need a full React Leaning Tower of Pisa stack for a simple presentational website.
kvirani 5 hours ago [-]
Nice. Curious about your views on SolidJS?
radicalbyte 7 hours ago [-]
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).
aidenn0 6 hours ago [-]
> ... 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.
xp84 7 hours ago [-]
> 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.
intrasight 3 hours ago [-]
> mixing presentation concerns with business-logic
That's on you not on your platform
fatplexer 6 hours ago [-]
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.
turtlebits 46 minutes ago [-]
Datastar relies way to much on IDs everywhere that it's not ergonomic and turns into a chore. It's also a bit too complicated for its own good trying to solve everything.
james2doyle 12 hours ago [-]
> `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
recursivedoubts 12 hours ago [-]
great library, we link to it on our alternatives page
zanderwohl 11 hours ago [-]
Carson! FYI:
"let us rething how extensions can and should work,"
I think you meant rethink here.
recursivedoubts 11 hours ago [-]
Proof it wasn't AI generated! Thank you!
threesmegiste 8 hours ago [-]
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.
miguel-muniz 8 hours ago [-]
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.
havaloc 13 hours ago [-]
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.
matthew-craig 10 hours ago [-]
What about vibe coding makes HTMX something that you speak about in the past tense? Are you just generating frontends in vanilla JS now?
havaloc 2 hours ago [-]
It's day job tasks/database CRUD, so I tell the LLM what I need. I used to write all my work apps in plain jane PHP/MySQL and I use that as a guide for the LLM, as in use this app as a guide on how I want things. The bonus of using plain PHP/MySQL/PDO is that the apps are small, so no issues with context windows or using complex frameworks.
LVB 9 hours ago [-]
For me, I know backend development really well, and HTML/CSS passably. HTMX has been much lower friction for me than learning JS frameworks, which tbh I didn't really enjoy, and they were constantly changing. But now, I had mostly leave the JS to Claude, and the HTMX draw has diminished a bit.
Baguette5242 14 hours ago [-]
As CEO of HTMX, I am very proud of the work achieved by the team.
all2 13 hours ago [-]
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].
> 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!
recursivedoubts 13 hours ago [-]
lol sorry about that, had a fix sitting in four-dev, merged to four and pushed, should be updated
bluesnowmonkey 8 hours ago [-]
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.
thewhitetulip 3 hours ago [-]
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
hmokiguess 9 hours ago [-]
For those wondering, here's how you can join me, the CEO of HTMX, as CEO of HTMX: https://htmx.ceo/
fionic 4 hours ago [-]
The site is very broken on my iPhone safari. If I click an an anchor reference at the very top (“LLM” let’s say) and try to scroll down because it doesnt link me to the content, it keeps snapping me back to the top after a second.
alkonaut 7 hours ago [-]
As the CEO of HTMX I find it disturbing that we have more CEO’s than users.
praseodym 14 hours ago [-]
Is it just a coincidence that the image for this release is the same as for Omarchy Quattro? https://youtu.be/F7fe9pa8OeE
recursivedoubts 13 hours ago [-]
oh man that's embarassing, someone made that on twitter I didn't realize it was from omarchy, I've removed it, my bad
chainwax 13 hours ago [-]
I think that's the joke
ryanisnan 13 hours ago [-]
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.
smt88 12 hours ago [-]
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.
mostlysimilar 10 hours ago [-]
> RoR and so poorly planned that it’s still biting Microsoft on a regular basis.
Disagree. The RoR front end was way more stable and usable than the mess they have made now.
smt88 8 hours ago [-]
The issues are with the Ruby backend.
RoR is the only framework I’ve ever heard of being so bad that it killed startups. I personally know of two that were doing well, but RoR was so brittle and slow that they couldn’t hire enough to keep it going. This is compounded by Ruby devs being pretty rare.
xp84 6 hours ago [-]
> RoR was so brittle and slow that they couldn’t hire enough to keep it going.
This is such a "poor carpenter blaming his tools" take.
RoR isn't holding you back from writing performant, high-quality code. However, letting inexperienced developers run wild without supervision does end up with a codebase committing most of the deadly sins of software: (1) proliferation of competing patterns (2) proliferation of competing third-party libraries, leading to more #1, (3) inadequate test suite, and (4) an app that serves up so many 500 errors that you can't tell which are new and/or which indicate a problem. #4 is definitely more common in untyped languages, since that whole class of bugs can't be caught at compile time.
By the time a lot of these "startups" get to the mature state they have like a 7-year-old codebase that is beyond help. But you can use Ruby and Rails responsibly. I've seen it done. Usually all that's needed is to apply yourself to understanding how to cache, and then, identifying the key expensive high-traffic endpoints and converting them from ActiveRecord N+1 messes into single-query eager-loaded beasts, sometimes skipping ActiveRecord's object instantiation. Sounds scary, but it's inevitable for a popular application on any language/framework that you'll need to go beyond the tutorial-grade code for key transactions. This kind of thing is what Staff Engineers are for.
ashwinsundar 9 hours ago [-]
Thinking about whether a web architecture will hold up for 100 years is bikeshedding, is bikeshedding as well
xp84 7 hours ago [-]
calling thinking about bikeshedding, bikeshedding, is peak bikeshedding.
ashwinsundar 5 hours ago [-]
bikeshed
euroderf 3 hours ago [-]
pronounced "by-kesht"
smt88 8 hours ago [-]
Only if you don’t know what bikeshedding is and want to broaden the definition so much that it’s meaningless.
This is Hacker News. This is exactly the place to tell people they’re overanalyzing and should just build something.
ashwinsundar 40 minutes ago [-]
Sir, this is a Wendy's
satvikpendem 11 hours ago [-]
100 years, sure, but 10 years? Definitely not bike shedding, I'd hope your website can stay up for 10 years at least.
smt88 8 hours ago [-]
You don’t need to agonize over a library choice to know that your site will be up for 10 years. If it outputs web standards, the browser engines will make sure it is.
satvikpendem 3 hours ago [-]
Yes, unless you choose wrong, which is what we're talking about, as sometimes choosing right is worth the bike shedding.
ryanisnan 11 hours ago [-]
Sure but it's a spectrum. Surely some choices will age much more poorly than others.
dajonker 9 hours ago [-]
Cheers! We've been running the various betas in production for a couple of months now. For our Rails app we replaced most of our Hotwired/Turbo with HTMX. For me at least, HTMX just makes more sense: you control the flow of content from the client, not from the server as you do with Turbo.
For pushing updates, we use ActionCable, but we do it in a different way from what we used to do with Turbo Streams: when a record is updated, instead of sending HTML from the server to the client with instructions on what to replace, we only send a small JSON payload with the ID of the element that was updated. On the client side, an event is dispatched that any DOM element with <hx-trigger="<resource-id>:updated from:body"> will trigger on. For the rest it's just basic HTMX, only the trigger is "custom".
replwoacause 13 hours ago [-]
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.
gregwebs 11 hours ago [-]
By default LLMs will start creating a tangled hard to test mess of javascript. But if you ask them to do TDD they will, and if you give them access to Playwright and have them write playwright tests this can all work.
The advantage for the LLM is the same for humans. With the right abstractions, code can be written quicker and more robustly.
To get more hands off with LLMS you really want to have a lot of engineering rigor. A big part of that is a focus on tests. If your abstractions make testing easier, your results will be a lot better. For Javascript the more you can test logic without DOM manipulation and without playwright tests, the better.
I found LLMs to be default to and be pretty good at working with HTMX, but not great (mostly lots of state synchronization issues). The focus on DOM markup of HTMX does not lend itself well to simplifying testing. I don't claim to be an expert at HTMX, but I don't see a separate section on testing in their documentation.
I am trying out the foldkit framework because it makes a lot more testable outside the DOM. Its probably too heavy weight for most humans (and for simple apps- it only seems appropriate for client-side apps), but I will see how well LLMs can work with it.
11 hours ago [-]
recursivedoubts 13 hours ago [-]
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.
sroerick 10 hours ago [-]
It may do the opposite! My sense of LLMs is that simplicity beats training.
If you have 1/5th the context to consume, that's going to generate better code than the comparable typescript, even if the language is an esoteric one.
giraffe_lady 12 hours ago [-]
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.
sroerick 10 hours ago [-]
I agree with this and I'd also say - I've been vibe coding in OCaml since before the training data was good.
All the stuff I lost in training data I gained back in having great compiler feedback.
I don't think agents are nearly as restricted by language or training data as we think.
recursivedoubts 10 hours ago [-]
We will see. Changing things around a bit (especially flipping attribute inheritance to explicit by default) may confuse a lot of models. Oh well, it's the right thing ¯\_(ツ)_/¯
Thank you for your kind words!
replwoacause 6 hours ago [-]
Please don’t misunderstand my comment, I wasn't trying to diminish the brilliant work you’ve done on HTMX, which I’ve personally benefited from. I could have probably worded it better than I did. I'm also not saying you _did_ misunderstand it, only asking that you please don't. I was just sharing an observation that I realize is not everyone’s experience. I’m still a fan + supporter, even though I now reach for JS more often because the pain of writing it has largely disappeared. I’m still not a fan of it by any means, but LLMs have been a major mitigator. I'm always happy to see the HTMX updates when they come out.
cyanydeez 10 hours ago [-]
I've yet to see anyone try to finetune one of these qwen models on a specific framework, but if you guys care, qwen3.5-35B-A3B is rather fast and reliable for a lot of what I'd call "copy/paste" task and might be worth while to see if a fine tune could excel at HTMX universe tasks.
vb-8448 11 hours ago [-]
The main issue HTMX address is reducing complexity and LLMs doesn't solve it.
I'd expect it to be the other way around: LLMs will increase HTMX(and similar solutions) adoption because alongside of being excellent at writing HTMX there are also excellent writing web components.
React, vue and similar still have their use case, but htmx + web components can drive you really far.
dgabriel 10 hours ago [-]
Out of curiosity, are you defaulting to vanilla js in your agentic dev stack? Or do you have the llm use a framework like react?
replwoacause 2 hours ago [-]
I've only tried vanilla JS so far
Fervicus 11 hours ago [-]
> now that LLMs can generate JavaScript for us.
You mean generate unmaintainable JavaScript for us.
replwoacause 2 hours ago [-]
Not my experience. I have large production apps that I'm able to maintain just fine with thousands of lines of JS.
razemio 10 hours ago [-]
Depends how you set it up. Like any other project I guess. Funny enough, if you are able to produce maintainable code with an llm you could aswell lead a team of humans. LLMs shift your focus on project management and architectural choices.
I let the llm write components which are independent to each other. This works great and keeps everything clean. The times that llm would only generate unmaintainable code are long gone with OPUS, Fable and sol 5.6
mi_lk 6 hours ago [-]
Does HTMX not have some performance gain over JS frameworks? (Never used it before)
KPGv2 12 hours ago [-]
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
Capricorn2481 12 hours ago [-]
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?
sgt 12 hours ago [-]
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.
nchmy 13 hours ago [-]
the browser is and always will be built for dealing with SSR HTML
replwoacause 13 hours ago [-]
All apps I build are server-side rendered. I'm not sure how your comment changes the the question I'm asking.
nchmy 12 hours ago [-]
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!
replwoacause 2 hours ago [-]
Ah no worries. No SPAs for me, SSR all day.
osigurdson 12 hours ago [-]
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.
KPGv2 12 hours ago [-]
That's like rejecting video games because the CRT was built for displaying live TV streams sent over the public airwaves.
7bit 13 hours ago [-]
Oof bold claim
nchmy 12 hours ago [-]
how so? that's what they do - incomparably faster than dealing with JS
tdhz77 47 minutes ago [-]
Htmx. And then what’s your mobile strat?
avarun 13 hours ago [-]
Why did they skip version 3?
MichaelNolan 13 hours ago [-]
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.
SoKamil 9 hours ago [-]
Exponential versioning. Next major would be 8.
_doctor_love 13 hours ago [-]
Carson promised they'd never do a version 3...but he never said they couldn't do a version 4.
gwking 12 hours ago [-]
I'm so pumped for v8!
recursivedoubts 12 hours ago [-]
this guy gets it
kayson 13 hours ago [-]
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?
recursivedoubts 13 hours ago [-]
htmx is based on the ideas of hypermedia, you can read the first chapter in our book on the topic here:
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.
Capricorn2481 12 hours ago [-]
HTMX is a polar opposite to Angular in terms of complexity, for one.
tflinton 5 hours ago [-]
I just discovered this and it’s exactly what I’ve been hoping for since 2016. I’m just sorry I’m JUST finding out about it.
arjie 13 hours ago [-]
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.
cui 10 hours ago [-]
It seems this version is also adding hx-live. Anyone used it before? How does it compare against Alpine.js?
hollowturtle 10 hours ago [-]
"On this page" anchor navigation doesn't work for me :( Mobile Safari
jamesforestwest 9 hours ago [-]
Cool to see htmx alive and evolving. This update was long overdue. The change to attribute inheritance seems a bit debatable to me but maybe it'll actually make the code easier to understand
flossly 12 hours ago [-]
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.
anamexis 12 hours ago [-]
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).
hackingonempty 12 hours ago [-]
You can use ReScript with Htmx (or anything else) and get no runtime errors. It has a sound type system, great language.
orsenthil 9 hours ago [-]
Strange. The picture of the jeep looks similar to the Omarchy Quatro Desktop wallpaper. Is there a connection? How come both look so similar?
Great to see progress continues and the CEOs continue to grow.
alsanan 7 hours ago [-]
disappointing: not a mention to "fixi" in any comment. Fixi is the reason htmx 4.0 has come. Fixi is extremately simple but extremately powerful at a time. http://fixiproject.org/
Better than htmx IMO.. Same author.
nothrowaways 9 hours ago [-]
That's a great-looking Toyota. What model is it?
recursivedoubts 8 hours ago [-]
40 series landcruiser
StrangeSound 13 hours ago [-]
> Note that attributes like hx-disinherit
Looks like some copy is missing here
recursivedoubts 13 hours ago [-]
Yep, fixed
mkl 13 hours ago [-]
> (plus at game)
Typo of "a"?
recursivedoubts 13 hours ago [-]
with enough eyes all typos are shallow (it was a long night)
Full Disclosure, I am CEO of HTMX
https://x.com/htmx_org/status/1726986945430233323
> You can put it on your LinkedIn, because it’s true.
I only take LinkedIn seriously under extreme protest, so this is extremely tempting.
Please take a look at the official documentation for htmx, which specifically clarifies that the author owns many hinges.
Absolute madman.
It's just about all Twitter links, where's XCancel/Nitter when you need 'em :(
> Full Disclosure, I am CEO of HTMX
i think you've found a good job!
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-...
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).
Skill.md here: https://github.com/dunctk/rasx-app-framework
And if you do, why start with a simpler framework?
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
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)
I'm not sure why so many people seemingly fall into the trap of trying to find one tool and then use that absolutely everywhere. I mean, I'm familiar with it as in "it's fun" as I used Nix as a framework for a static website builder, but I keep seeing people making those sort of choices professionally too. Like when React first became popular, then suddenly people try to jam it into absolutely everything, until they slowly walk back and then after some years agree that maybe it's good for some things, not for everything and not as a default.
And, yeah, HTMX is truly great for sites with limited interactivity. You really, really do not want or need a full React Leaning Tower of Pisa stack for a simple presentational website.
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).
Do you not have a database for your backend? Managing state is kind of their thing.
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.
That's on you not on your platform
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.
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
"let us rething how extensions can and should work,"
I think you meant rethink here.
[0] https://www.youtube.com/watch?v=GyV_UG60dD4
For what? Don't leave us hanging!
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.
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.
Disagree. The RoR front end was way more stable and usable than the mess they have made now.
RoR is the only framework I’ve ever heard of being so bad that it killed startups. I personally know of two that were doing well, but RoR was so brittle and slow that they couldn’t hire enough to keep it going. This is compounded by Ruby devs being pretty rare.
This is such a "poor carpenter blaming his tools" take.
RoR isn't holding you back from writing performant, high-quality code. However, letting inexperienced developers run wild without supervision does end up with a codebase committing most of the deadly sins of software: (1) proliferation of competing patterns (2) proliferation of competing third-party libraries, leading to more #1, (3) inadequate test suite, and (4) an app that serves up so many 500 errors that you can't tell which are new and/or which indicate a problem. #4 is definitely more common in untyped languages, since that whole class of bugs can't be caught at compile time.
By the time a lot of these "startups" get to the mature state they have like a 7-year-old codebase that is beyond help. But you can use Ruby and Rails responsibly. I've seen it done. Usually all that's needed is to apply yourself to understanding how to cache, and then, identifying the key expensive high-traffic endpoints and converting them from ActiveRecord N+1 messes into single-query eager-loaded beasts, sometimes skipping ActiveRecord's object instantiation. Sounds scary, but it's inevitable for a popular application on any language/framework that you'll need to go beyond the tutorial-grade code for key transactions. This kind of thing is what Staff Engineers are for.
This is Hacker News. This is exactly the place to tell people they’re overanalyzing and should just build something.
For pushing updates, we use ActionCable, but we do it in a different way from what we used to do with Turbo Streams: when a record is updated, instead of sending HTML from the server to the client with instructions on what to replace, we only send a small JSON payload with the ID of the element that was updated. On the client side, an event is dispatched that any DOM element with <hx-trigger="<resource-id>:updated from:body"> will trigger on. For the rest it's just basic HTMX, only the trigger is "custom".
The advantage for the LLM is the same for humans. With the right abstractions, code can be written quicker and more robustly.
To get more hands off with LLMS you really want to have a lot of engineering rigor. A big part of that is a focus on tests. If your abstractions make testing easier, your results will be a lot better. For Javascript the more you can test logic without DOM manipulation and without playwright tests, the better.
I found LLMs to be default to and be pretty good at working with HTMX, but not great (mostly lots of state synchronization issues). The focus on DOM markup of HTMX does not lend itself well to simplifying testing. I don't claim to be an expert at HTMX, but I don't see a separate section on testing in their documentation.
I am trying out the foldkit framework because it makes a lot more testable outside the DOM. Its probably too heavy weight for most humans (and for simple apps- it only seems appropriate for client-side apps), but I will see how well LLMs can work with it.
If you have 1/5th the context to consume, that's going to generate better code than the comparable typescript, even if the language is an esoteric one.
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.
All the stuff I lost in training data I gained back in having great compiler feedback.
I don't think agents are nearly as restricted by language or training data as we think.
Thank you for your kind words!
I'd expect it to be the other way around: LLMs will increase HTMX(and similar solutions) adoption because alongside of being excellent at writing HTMX there are also excellent writing web components.
React, vue and similar still have their use case, but htmx + web components can drive you really far.
You mean generate unmaintainable JavaScript for us.
I let the llm write components which are independent to each other. This works great and keeps everything clean. The times that llm would only generate unmaintainable code are long gone with OPUS, Fable and sol 5.6
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?
That doesn't mean do dumb / complicated / bloated stuff for no reason. If the best thing for your users is static html, use that.
https://hypermedia.systems/hypermedia-a-reintroduction/
Nonetheless I hope all who do use Htmx, enjoy using it.
Better than htmx IMO.. Same author.
Looks like some copy is missing here
Typo of "a"?
(Congrats on the release)