HTMX is better if you have a frontend bundle that does just enough but no more. Hook into the htmx.onLoad event and then look for markup with attributes in the content being loaded (for example, columns, cards, tasks, etc) to attach to. You can then, for example, bind sortable.js onto the rendered markup, and then wire sortable events to state updates via HTMX. Really pretty straightforward. They even have an example of exactly this in the docs: https://htmx.org/docs/#3rd-party
It's obviously tongue-and-cheek but I think it makes the case well!
the htmx sucks essay was definitely tongue-in-cheek though (although many of the criticisms were legitimate, and even agree with this one, such as the lack of a component ecosystem!)
https://htmx.org/essays/when-to-use-hypermedia/
and then this tongue in cheek essay (many of the criticisms are legitimate):
https://htmx.org/essays/htmx-sucks/
We also have a mug for people who don't like htmx:
Wasn't able to relate to other puns all that much unfortunately.
Arguments like "React is popular, AI knows it", or "React is popular, lots of component have been written in it" seem weak.
A proper antithesis for htmlx should compares it with SPA.
What's an SPA if not a single web page where clicking on things causes that UI to update in-place in different ways?
In SPA server just serves a single page and routing is all done in the client.
Like, it's rare to come across htmx (or svelte, or solid) in a corporate job for now, which means that almost all of their users like said frameworks enough to use and talk about them in their free time
For react that's just not the case, because it's everywhere. If I was forced to use Vue, I wouldn't like it. But I'm not so I don't use it enough to criticize it a lot.
If anything I've seen more people dislike angular or vue when they had to work in a project that used those frameworks, and didn't have a say in that choice. But that's also just an anecdote obviously
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.
Anakin Padme meme: "You still implement validation on the server-side as well, right.... right?"
You can split the validation in multiple functions/modules which you can then use both at submission or per step/page.
Also, it seems you're implying having two validation systems (on the client and server) is actually good?
You want to validate on the client side because it reduces latency and improves responsiveness.
You want to validate on the server side because you cannot trust the fucking client.
And I'm not saying you should be only validating on submit when using HTMX.
Client exclusive validation is quite limited. Very often you need a trip to the server anyway so I don't buy the latency argument.
Plus in most cases showing error messages too fast is terrible UX. The only exception I can think of is when checking the validity of a password.
The solution to that problem is to debounce or throttle your error messages. That allows you to report validation issues to the user quickly, but not overwhelmingly fast, before sending a network request potentially across the Earth and back.
Note that frontend forms libraries allow a lot of choice over when to show error messages.
https://fatiharslan.gumroad.com/l/dieter-rams-inspired-vinta...
Maybe I'm a Luddite but I just get the feeling that we've gone very wrong in our over-engineering.
They migrated pretty quick to react after the acquisition due to team dynamics (offshore big teams - seeped into JS heavy client, thin server culture). htmx was a struggle there as well.
It worked amazing for us as a small team where everyone was full stack and I always build using htmx-first now. But, it is a struggle for folks who have been working in React-like patterns for 5+ years and never experienced the bless of MVC apps.
haha, good one
One advantage of htmx (along with web components and standard html+css) is that migrating to anything else is much easier than the other way around. A rewrite from an htmx app to a React app can be trivial. A rewrite from React to anything else will not be.
This is stated as a very matter-of-fact downside, but this is a pretty crazy portent for the future of dev tools / libraries / frameworks / languages.
Predictions:
- LLMs will further amplify the existing winner-take-all, first-mover nature of dev tools
- LLMs will encourage usage of open-source tools because they will be so much more useful with more/better training data
Future frameworks will be designed for AI and enablement. There will be a reversal in convention-over-configuration. Explicit referencing and configuration allow models to make fewer assumptions with less training.
All current models are trained on good and bad examples of existing frameworks. This is why asking an LLM to “code like John Carmack” produces better code.. Future frameworks can quickly build out example documentation and provide it within the framework for AI tools to reference directly.
What I mean is: if you name your modules consistently, say Operation::Object::Verb or Action::ObjectVerb or ObjectManager.doSomething it's really easy for the LLM to guess the next one, just as it is easy for a human.
Add a new file actions/users/update.rb and start typing "Act" and it may guess "class Actions::Users::Update, and start to fill in the code based on nearby modules, switch to the corresponding unit test and it'll fill it in too.
Source: we have our own in-house conventions and it seems copilot gets them right most of the time, ymmv.
- developers will be incapable of writing or debugging code for development stacks or project types without LLMs trained on lots of matching examples
LLMs are often wildly good at being universal translators. So if they pick up general patterns and concepts in popular frameworks, and enough syntax of more niche frameworks, IME, they do a pretty great job of generating good niche framework code.
Similar to how they can talk like a pirate about things things pirates never said in their training data.
If you mean plausible looking code, yes - totally!
If you mean actually usable code: nope. Its always riddled with imaginary library calls that don't exist.
This will be true for people who rely on LLMs to code, which I strongly suggest is not a great long-term bet for a software engineering career.
I know other methods are more efficient. But I’m here to experience life. I want to do the hard things. I want to be uncertain, confused, to make mistakes, and to learn.
AI is a neat tool in limited scopes. Every time I use it though, I feel like I didn’t get the full experience. I’m acutely aware of all the rabbit holes I missed, or the tiny details I’d notice along the way and helpfully remember 10 years later. For everything it adds, it takes at least as much away from where I’m looking. And I like those parts.
All of these have existed in huge numbers for a decade or close to it. This isn’t interesting. It wouldn’t have taken much to do this without AI if these people found motivation through some other means. Nothing notable is happening yet.
That doesn't always matter though; I saw some guy on reddit selling 1000s of subs of a server uptime page they generated with an LLM (Cursor I think it was). Most do it for the money and that is working IF you have the following somewhere.
That's pretty much the same as what you got from old school stackexchange. The LLMs are trained on poor example data (e.g. from stack exchange) and I presume it is a hard problem to filter for just the "good" training data.
The why behind a design decision is something an LLM can't understand simply by being fed the decisions themselves. Hence, though they often stumble into the right answer, they only ever do so because it "seems right based on context," and so they can easily apply a principle correctly one moment and then misuse it the next.
If all a compiler did was spit out a slurry of buggy assembly that misunderstands its context and has to be carefully scrutinized for errors, I would still be writing assembly the old fashioned way.
I am currently in the process of hiring a backend engineer. Anybody who does not use AI to aid development work gets an automatic disqualification. In my experience, a good engineer using AI tools will run circles around a good engineer not using AI tools.
AI does help an engineer who embarks on a new voyage through unfamiliar APIs to guide them with usage patterns, but some people become much more efficient by going through the library docs.
Typing out the code is the smallest part of a "good engineer's" job (and even so, having to adapt most of AI generated code is slower than typing it out yourself once you do understand the APIs).
I do think it might work well for MVP-style quick prototyping, but using this as an applicant qualification criteria seems so weird (even when building an MVP, you want some tension between building it quickly and building it the right way).
Even supposing that is true, what if you have a choice between a bad engineer who uses AI and a good engineer that won't?
AIs generate deeply mediocre code. This is better than anything a person who can't code on their own would produce, but an experienced developer will have to spend all their time babysitting the AI to get it to behave properly.
There is a lot, of course, one can't take 1:1 into the final product, but it helps to find the right libraries, helps to find patterns, the right parts/functions to use where verification in the applicable documentation or source is a lot simpler than finding it in the docs to begin with.
Using it as a tool, while not a source of truth can be good.
And don't get me started about writing all the boilerplate which sometimes is needed, which is too complex for a simple editor shortcut, but too tedious for me as a human. That I review and fix a lot faster than create by hand.
Recently I used Cursor with an in-house developed language and it was able to get almost perfect completions upon seeing ~100 lines of context.
Not all LLMs are equally good at this: Gemini seems to be particularly resistant to adapting to a new syntax
Or, taken another way-- developers not using LLMs will be more likely to be first-mover winners.
i'm doing some game development in godot as a hobby, and the current llm's are really bad at it - very often i get code suggestions that use ancient versions of gdscript or the engine. I'd love to have a big enough context window and the tooling needed to go like "look at these godot docs for the current version: (insert link)" and then ask my questions, i think it would fix 99% of these issues. same with other less well-known tools and languages.
This reeks of ad-hoc vibe-driven development.
I used it recently to build a small crud admin page and I soon reached the limits of the technology; in the ends I rewrote it in solid.js - because next.js / react are pretty slow and employ the wrong abstractions.
I think htmx for static + solid.js for interactive is a great combination - albeit I dream of a framework which will excel at both.
It seems htmx stopped working as soon as you gave up on the super light frontend part :)
You started using third party libraries to render complex UI/UX and state management.
Also, I’d like to point out that saying “it was easier to do X in React” is not really fair if you did that using third-party libraries. It’s just that somebody did it for you so that you didn’t have to.
I sympathise a lot with what’s written in the post actually but in this case I think that htmx was not a good solution from the start if you knew you needed to manage complex states and rendering.
Nothing in this post indicates that the author doesn’t know any of what all these people in the peanut gallery are snarkily lecturing about, FFS. Working in the open must be so difficult.
I am not a frontend specialist, but I do find it interesting, but here are some of my thoughts on the points made:
1) Don't they have to validate forms on the backend anyway? What made it so difficult to get their backend system to communicate back up to the frontend? There are absolutly great reasons in many cases to do form validation on both the frontend and backend, so in those cases you would want more than just HTMX, but I am a little confused at the phrasing of this issue?
2) HTMX alone may sort of push apps in this direction. In some cases that is a good thing, but apparantly they decided they need to do somthing different for their customers. I hope it was a good decision for them. I do think HTMX could be used effectively to make a site much less CRUDy, but I can't really argue with their results in this specific case.
3) This is an interesting argument. I would love to know more about how this team using AI tooling and has become so dependent on it that this was a major issue for them. It also brings up an interesting question for the future- if AI dev tools become a major thing, will it raise the bar too high for new frameworks/programming languages to get enough tooling an integration for adoption? Not particularly relevant to Gumroads decision making process, but an interesting line of thought.
4) A common complaint with HTMX. I think some projects just require more than just HTMX provides. Maybe future HTMX plugins will fill in this gap though?
5) Certainly a legit issue. One reason I like Django (and even Python) is because of its deep community of integrations and add-ons.
Perhaps they would have better luck with something more full featured like https://unpoly.com/ would fit their needs better than HTMX, while still being similar to the concept?
when I prompt for rails stuff, things work right out of the box, and it makes great suggestions. (although this may no longer be the case for rails 8 - solidqueue/cache/etc are out that are totally new!)
when I prompt for elixir/phoenix stuff, I usually have to paste in documentation or it hallucinates features or worse, suggests very dated ways of doing things that no longer apply or even work!
react/next has so much volume of data that the AI must be cracked on it fr.
I'm not a web developer [1], and I get that htmx uses JavaScript behind the scenes, but this quote seems like someone was missing the point. htmx encourages a different approach to architecting and building an app. Or am I the one who's not understanding?
The comment about hiring and AI-support being better with React is imo just another depressing reminder of how much of a monoculture we have at the front-end - and imo a bloated and over-complex one at that.
[1] I have read the htmx book though
Imagine a world where companies pay to have their framework’s be over represented in a models training set and selling contracts off the back of that.
Like SEO but baked into developer tooling.
What part of this ReactJS syntax you find natural? Familiar Yes, Natural NO.
useEffect(() => {
const timer = setInterval(() => {
setCount((prevCount) => prevCount + 1);
}, 1000);
return () => clearInterval(timer);
}, []);
I've received two spam emails from them in the past week, where a seller "sold" me something for $0, with a cryptocurrency scam in the item description - so I received an email from a legit gumroad address, but with attacker-provided content (text only in the email at least).
I submitted one through their form, but it's a Google Forms page configured to only allow a single response, so I could only submit once. I also forwarded one to "[email protected]", but no clue if that's a real destination or the best place for it...
Gmail flagged both of these as Spam, so while I'm not really concerned about my own security here, I figure gumroad themselves would at least like to know about this so they can limit the (spam list) reputation hit...
HTMX is a breath of fresh air where 10 other framework aspects aren’t in my way. Gumroad from reading this didn’t even try to design using the htmx methodology.
The point is, it could be a whole lot easier to self-host Next.js. There's a reason it's not.
A Haiku on the above, oft-repeated, sexy-problem-to-have:
Everyone says this,
but nobody has benchmarks,
because its not real
You are not Google,
but make believe problems,
Are the most fun ones!
Good websites behave in predictable ways. If I can tell your website is using fucktons of javascript, I'm probably not enjoying using it. (And calling it an "app" is a bit of a red flag for bad UX to me.)
The system is a document management tool which can be configured to be a lot of different things like an image sorter or an RSS reader or an information extraction tool. The key design point is that it has to be easily configurable.
I worked on a similar system at a startup that used an SPA and boy was it a bear because changing anything involved making both front end and back end changes. We had to change directions all the time to keep up with our customers and the monolithic SPA sure slowed us down.
My current back end has a query builder that can generate queries with a complex structure as is supported by OWL DL, like
(Temp > 95 AND Temp < 100) or (IS warm)
but with HTMX I can best use URL query parameters like ?temp:gt=95&temp:lt=100
that are all ANDed. I am thinking about making little applets with svelte that could do what HTMX can’t. ?query={entire query goes here}
Rather than splitting it up into multiple query params? Feels like it's one indivisible param rather than multiple facets. You could always base64 encode if it starts getting complexFull text fields would be harder as the front end is going to want to put them in their own query parameter although one attack on the problem is to have the query as a parameter and have parameters that define a command that changes the query and have the back end mash that into the query.
The user interface for nested queries would be more complex than for the flat queries (which can usually be updated incrementally, adding or removing just one tag) but could probably be redrawn from the back end whenever it changes.
Now, it's a bit of a safe bet to write off anyone willingly or willfully using react, but still, actually hosting this took some real flair.
IDK, I'm a svelte(kit) man myself, but I don't know that dev-dom really deserves something that makes as much sense as that. htmx is so far from the worst idea out there.
But the web is (and should be) different than mobile, whenever possible. The post says that their designs were too "generic" as a CRUD app, but is that such a bad thing? We have a universally adopted document model (a momentous task) so we could have a predictable user experience across all sites but we can't help but see that as "boring". As if there's something inherently wrong with boring.
I understand the market pressures to have a unique and branded experience that feels like a mobile application, but imagine if designers could think in WWW as well as they've learned to think in React.
So 99% of the production sites out there. Good thing I didn't invest into htmx when it was the flavor of the month.
Feel free to pass on htmx but don't convince yourself that it can't handle "complex forms" because this particular group of knuckleheads preferred React.
I do wonder how you can feed your docs to the maw of the AI machine? Can you tell if they scraped your docs?
I find this bit to be disingenuous. I doubt "straightforward client-side operations" can handle "complex forms with dynamic validation and conditional fields", but it's probably true that such things are much easier (but not straightforward) in React than HTMX.
There's no rule that says everything needs to go to the server and back when using htmx. You don't have to _not do_ client side scripting. There's a whole section in the hypermedia book based on client side scripting. This is why most people using htmx are also pairing it with a light library for client interactions (alpine, hyperscript, web components, etc). Heck-- you can even pair it with react or any of the other heavier libraries.
Why is no one mentioning embedding a js bundle in an htmx rendered page?
My experience with nextjs was a few deps now had vulns (fair enough, I’m grateful for the npm tooling that informed me) which necessitated updates which were a bit distracting and felt like yak shaving when all I wanted to do was a simple change. Even when there aren’t vulns I find it a bit lazy not to take the opportunity to evergreen the dependencies for a bit longer but that does frequently cost unwanted time.
One place where htmx feels underpowered is when you have multiple related states on a page - a table view with some summary metric fields across the top as a dashboard and some action items in a sidebar with labels exposing counts of actions. In htmx you can always resort to hxswap basically the entire view out rather than trying to surgically update each dependent target but at that point why am I using htmx, I can just round trip for a page refresh and skip the whole hassle of having a server side component strategy.
I have always been a reader of documentation for libraries that I use, and I have nearly always felt that docs could be better. Having tried to write docs myself, I know how hard (impossible?) it is to imagine not knowing how the thing you are documenting works.
Recursivedoubts, please take this criticism as encouragement more than anything! I think HTMX is important both as a library and as a reality check against complexity.
There is something unnerving about the HTMX docs to me: over and over again, I read them, and I think, "ok got it, sounds straightforward" but then it turns out there is something slightly tricky that is hard to diagnose. I don't quite know why.
One thing that has gotten me a couple times is not being clear on whether an attribute is for the request or response. I feel kind of dumb admitting this but it has been harder than I'd have thought. My best suggestion would be to add a request/response column in the attributes reference listings. Debug mode validation of "hx-*" attributes would be very welcome.
Early on I definitely mixed up hx-select-oob/hx-swap-oob and hx-include/hx-vals. I've also made mistakes with hx-indicator/htmx-indicator although that's a little different because one is a css class name.
Another that got me recently was trying to set an hx-on: after-settle handler in the target element (client side) and having nothing happen, but then discovering that if I put it in the response it would work. This made no sense at the time. Now I'm wondering if it was because the hx-swap was set to something other than innerHTML.
Anyway, I think the main point is that some of these things are sort of related in various subtle ways, and also sound similar, and are easy to mix up. As a new user, when I try to follow the directions and then apparently nothing happens, it is very hard to know how to proceed. Really the only way forward is to find a working example and try not to break it, or selectively break it to figure out how it works.
I know docs are a lot of work, but in an ideal future there would be example links to click on for each one of the attributes. Perhaps I could help with that at some point.
I've always thought that HTMX has amazing potential on the documentation front because one can build working examples that are served completely statically. In fact I can't think of a UI system that is more amenable to training an LLM. You would just need to write out the expected end-state of the HTML target.
For context, I've been using HTMX as crucial component of a back office web app for two years now. It is mostly a custom scheduling calendar. Most of it is simple HTMX, but I've used OOB-swap and hx-on in places. I use it to do fast state changes without full page refreshes, and to implement a few multi-step forms that require back-and forth of valid form choices. Recently I built a modal control with different edit actions, etc. I don't think I would have taken on this client at all if it weren't for HTMX. So, thank you!
>> while it’s important to consider lightweight alternatives, it’s equally crucial to choose technologies that can grow with your project and support your long-term vision
A key takeaway that resonates with me is the importance of choosing technologies with growth potential and a thriving ecosystem – essentially making a long-term bet on their success. Too many devs get entangled with adopting shiny new things, while losing focus on delivering real value to customers.