This is a wonderful advertisement for the things that HTMX is good for and the thing it isn't. It's obviously tongue-and-cheek but I think it makes the case well!
What makes you think it was tongue-in-cheek? It sounds quite genuine to me?
Why Gumroad Didn't Choose Htmx
41–50 of 216 posts
Re: Why Gumroad Didn't Choose Htmx
#42I will start using htmx as soon as there is a 20K MRR startup built only with it.
Re: Why Gumroad Didn't Choose Htmx
#43I literally only ever hear about htmx from YC. I still don't know what the point of it is, it seems like one of those opinionated programmer things like "I don't use a framework" or "you don't need javascript to make my site work"
It's for python programmers who think front-end is an unavoidable evil but wish to avoid it anyway.
Re: Why Gumroad Didn't Choose Htmx
#44My comment from the other thread: 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.
Your attitude to call out where htmx might not be the best solution, makes me respect the project even more. It's refreshing to see this compared to lots of other projects that always seem to claim to be the best solution for everything. 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 tac…
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.
Re: Why Gumroad Didn't Choose Htmx
#45I 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?
Re: Why Gumroad Didn't Choose Htmx
#46> I thought htmx could be a good solution to keep our front-end super light. 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…
Re: Why Gumroad Didn't Choose Htmx
#47Kudos to htmx.org for hosting this essay.
It's really humble and honest of them to put something like this up but in the end at least they have something to point to now if people pick it up and get mad that it doesn't meet their needs
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:
Re: Why Gumroad Didn't Choose Htmx
#48My comment from the other thread: 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.
Re: Why Gumroad Didn't Choose Htmx
#49My comment from the other thread: 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.
Very useful explanation, because at first it seemed unusual to see it on htmx.org, but well, different projects have different needs.
Re: Why Gumroad Didn't Choose Htmx
#50> AI and Tooling Support: It’s worth noting that AI tools are intimately familiar with Next.js and not so much with htmx 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 to…
I was considering this other day. AI tools are stuck at a particular point in time. And even training them on newer stuff, there's only so much information to train on. I've been exploring this being a _good_ thing. In software we spend so much time chasing the latest tooling, language features, frameworks, etc. Maybe it'll be a positive that it all stagnates a bit and we just use the tools we have to get work done i…