The CEO of gumroad mentioned on twitter that he had tried out htmx for a project but decided to go with NextJS instead. I asked him if he was willing to write up his experience and he graciously agreed to do so. I have been looking for a thoughtful negative experience with htmx to host on the htmx website and I am very thankful he was willing to put in the work to produce one.
I'm curious in particular about the call out around drag-and-drop. Is that something you agree with? Is drag and drop difficult with htmx and if so, is that something you plan on tackling?
https://htmx.org/examples/sortable/
Like most of the examples on the htmx site it is pretty bare bones (we keep it that way to focus on the concepts) but it's a reasonable demonstration of the integration. Whether that is good enough of course depends on your use case
If you want an integrated and polished ecosystem that's something htmx isn't going to provide: it's a library focused (mainly) on one thing: generalizing hypermedia controls. So, when you want client side functionality like this, you are going to have to glue things together a bit. I completely understand the desire of having an integrated ecosystem to avoid doing that.
that being said: htmx makes it too hard to quickly add a fat frontend to a page when necessary. The points about the react ecosystem are very valid, even if drag and drop is an exception. The network effects of react and others are hard to beat. Its probably even more npm as a whole than just react.
wrote myself a framework with bun that solves this for me: https://github.com/spirobel/mininext
still get the pure html+css feeling like with htmx, but can throw in a big frontend when needed.
https://x.com/spirobel/status/1827231794934247674?t=moRzsWIP...
https://htmx.org/essays/when-to-use-hypermedia/
I think it's a good idea for any software project to have something like this so that people know when it's a good fit and when it isn't.
It might not have helped with wider adoption though. People would send me the link saying "Look at all of these bad things about Tor", and it would be links to Tor explanatory pages.
It was around that time that I realised that when trying to give people an intuition for what software many Internet professionals trust, the list of "green flags" I identified was, in fact, the exact opposite of what the majority might guess as being good signs. "Large list of attractive sounding features" vs "Lists problems with the tool as prominently as benefits" ; "Sold and marketed by a large well-known company" vs "Developed by a small, volunteer team" ; "Free to download" vs "Costs money"; "Modern, professionally-designed website" vs "Looks like it was built in 1997", etc, etc.
> I often see people believe in their solution and think theirs are better than the others. They defend their cases without having an exact reason. These situations often create long and meaningless discussions that go nowhere.
From <https://candost.blog/how-to-stop-endless-discussions/>. (Comments: <https://news.ycombinator.com/item?id=25622149>)
I don't think I'm explaining this well, but maybe this will help someone: Hotwire / htmx are about server-side rendering and making that work more smoothly with the client. eg fewer page navigations, more rapid update of the client, etc. But it's still, through and through, server render with server state.
It works well as long as the server is always the source of truth. The things that it isn't good at, such as drag and drop or complex, multi-state forms on the client side, are basically because you temporarily have a split source of truth: the client is the source of truth with complex state.
That said, my strong suggestion would be to use Hotwire or htmx for 95% of your project even if the main interaction loop is done in react. Your app will still likely have tons of crud around user management, settings / config, onboarding, etc. You can make all that work more nicely.
edit: in case it wasn't clear: for the things that are in the hotwire/htmx wheelhouse, the tech works really well. It's a fantastic improvement.
The trick is to be very honest with yourself (and team) about how much complex front-end UI the application actually _requires_. Using React where it isn't necessary is very expensive in the long run. The older I get, the more the grug brained developer makes sense.
Sometimes it’s not the best choice for the app I’m working on, but it’s always thr best choice for me.
Either this is missing /s or this is trolling, right?
Agreed 100%, hencq!
He also mentioned Rails in itself is a technical debt. And when asked about it all he said was React is so much better. As if you cant use React with Rails.
As for the article, I dont see it as a negative experience for HTMX. As soon as he mentions drag and drop, real time collaboration, I will go on to say may be even toying with HTMX was wrong in the first place?
I am also not sure what the screenshot was trying to show.
But all of that, I think it is a great pieces to be on HTMX website.
One of them is much easier to reason about than the other, even though the other is enviably compact.
Personally, I think rails and react go together very well. For apps that need rich client-side functionality, I will do a react spa with a back end in elixir/ Phoenix (which is very similar to rails).
For apps that don't, just doing server-side rendering is plenty sufficient and is my preference.
Verily, Rails can be a pretty good and compact way to serve backend APIs for a React-based frontend. But the API boundary is the "narrow waist", its relative neutrality allows to switch backend and frontend implementations easily, or even to mix them. I've seen a React frontend seamlessly consuming APIs served by Python and Rust services, and it's hardly possible to spot which endpoint is served by what in the frontend code.
Unlike on the frontend, FP approaches on the backend are not (as) widespread. Established imperative frameworks (Django, Rails, Spring Boot, etc) are still the huge majority.
Perhaps he meant Next.js? TFA mentions they are using Next.js
https://htmx.org/essays/htmx-sucks/
Has convinced me never to use or recommend htmx to anyone.
Mad props, my man. I love that attitude. To me it's making the world a better place in a tangible way.