Why Gumroad Didn't Choose Htmx

[recursivedoubts]

My 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.

[hencq]

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 tackling?

[ksec]

>The CEO of gumroad mentioned on twitter...

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.

[pseudosavant]

Much respect for showing where htmx might not be as suitable as other tools. In my mind htmx is more a replacement for jQuery than React. htmx and jQuery both augment documents with interaction. React tries to be the entire document. Different tools for different jobs.

[d13]

Thank you! The linked article, in addition to this,

https://htmx.org/essays/htmx-sucks/

Has convinced me never to use or recommend htmx to anyone.

[laserlight]

> other thread

https://news.ycombinator.com/item?id=41727315

[kunley]

Very useful explanation, because at first it seemed unusual to see it on htmx.org, but well, different projects have different needs.

[n3storm]

thank you so much, I am a user since intercooler.

[tuyiown]

This is a great initiative. Too much people with little experience with non trivial web are vocal about htmx, and it's not a good thing for the projet.

[tomcam]

> I have been looking for a thoughtful negative experience with htmx to host on the htmx website

Mad props, my man. I love that attitude. To me it's making the world a better place in a tangible way.

[dakiol]

Is it just me or the article smells like AI-generated?

[ketzo]

> 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 tools because they will be so much more useful with more/better training data

[markmark]

The AI and Tooling support point is really just an extension of the Community and Ecosystem point. Even before LLMs React had an advantage in that every question you had was probably already on StackOverflow and there are mature React libraries for almost everything. Now some people might use an LLM to answer the question they previously would have gone to StackOverflow for but the outcome is the same: there are advantages to using what other people are using.

[alexpetros]

> LLMs will further amplify the existing winner-take-all, first-mover nature of dev tools

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.

[ryanchants]

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 instead of creating new hammers every 6 months.

[SrslyJosh]

If your devs can't work without something writing their code for them, why are you hiring them?

[spankalee]

I'm not too worried about this, and I think Gumroad's concern is likely overblown. I can't tell from their comment whether they actually experienced AI being bad at HTMX, or if they transitioned to talking about other resources.

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.

[davidhaymond]

I had written a comment addressing this as well but you beat me to it. In a way it is similar to the effect StackOverflow had on popular libraries, but amplified. Even without StackOverflow, a library can do well if it has good documentation. I'm not sure if the same holds true with LLMs.

[killerstorm]

In my experience LLMs are good at picking up syntax from the context.

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

[diggan]

My prediction is that it'll be like this for a while, but as soon as tooling becomes better and the context of current APIs + local files gets better taken into consideration, this "advantage" will disappear.

[ClassAndBurn]

This will not be true for future frameworks, though it is likely true for current ones.

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.

[bitbasher]

> LLMs will further amplify the existing winner-take-all, first-mover nature of dev tools

Or, taken another way-- developers not using LLMs will be more likely to be first-mover winners.

[wodenokoto]

I saw a tool that had a page dedicated to AI to read. Basically you would point your llm to that page as the initial prompt and from there could start asking questions. I thought it was an interesting idea, but apparently not interesting enough to remember who did it or even check how that page looked.

[jimbokun]

And:

- developers will be incapable of writing or debugging code for development stacks or project types without LLMs trained on lots of matching examples

[wwarner]

respectfully disagree. i think that the value of llm suggestions are driving us toward a kind of standardization that is really good. we'll all be java programmers soon!

[simonw]

"For example, when building complex forms with dynamic validation and conditional fields, we found ourselves writing convoluted server-side logic to handle what would be straightforward client-side operations in React."

Anakin Padme meme: "You still implement validation on the server-side as well, right.... right?"

[skydhash]

If your web form is more complex than a paper form, maybe rethink the former? I can not think of a form that can be implemented easily in react, but is difficult in Htmx other than wishing to plug in a React-like global application state and having the job 90% done as libraries.

[mplewis]

Yes. But you do it once at submission, not once per page.

[mattrighetti]

> 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 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.

[smallerfish]

> For instance, implementing a drag-and-drop interface for our workflow builder proved to be a significant challenge with htmx, requiring workarounds that felt clunky compared to the smooth experience we could achieve with React libraries.

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

[hakunin]

Having read the article, the team just seems more experienced with frontend than backend dev. As somewhat an old school dev, I've been noticing these small fears and misunderstandings in the way FE devs think. Honestly, I believe it only takes a minor adjustment in thinking to understand how this stuff works, but I get it — many people at this point have never seen regular client/server approach in their entire careers. That said, I get the value of off-the-shelf React components, and ease of finding docs/help, so wouldn't discount that anyway.

[ensignavenger]

I love that HTMX is posting this (and other similar things) on their site. It seems like there were a lot of legitimate reasons why HTMX alone was not a great fit.

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?

[meerab]

"The development process felt natural with Next.js" - the author

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);
  }, []);

[bumbledraven]

Kudos to htmx.org for hosting this essay.

[dannyobrien]

I really do value services/tools that explain why you shouldn't use it, as well as why you should.

[jamal-kumar]

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

[svat]

Yeah it's linked from https://htmx.org/essays/ under "On The Other Hand…"

[Ayesh]

Yeah, I expected a bit of a rant or sarcastic post, but I'm genuinely happy it's a good post with good points. I use htmx in a couple of my projects and it's been great! Posts like these give me more confident about using htmx because they seldom show where they excel and where they fall short.

[dartos]

His 3rd point scares me.

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.

[nop_slide]

Gumroad dude seems to have some shaky reasoning for migrating at all, sounds to me a migration just for the sake of it.

https://news.ycombinator.com/item?id=41669615

[righthand]

NextJS while solves a lot of problems is one of the most irritating frameworks I’ve worked with from their odd required directory structure to their weird router shift, to the shoehorning of server side api controllers and rendering. Not to mention the specific requirements to host on Vercel.com and it’s intentionally misleading design to get you to host there.

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.

[CraigJPerry]

One quality of htmx that a nextjs solution won’t benefit from is stability. I have come back to an htmx project months later and been able to very quickly change a behaviour.

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.

[zackerydev]

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!

[WD-42]

Here is what I don’t understand about this post: if they knew they needed complex ux with realtime collaboration, why did they even reach for HTMX to start with? The author could have spent an hour going through the HTMX docs and would realize it’s not a good fit instead of wasting who knows how much time actually implementing it.

This reeks of ad-hoc vibe-driven development.

[rossdavidh]

Funny, almost everything he said about htmx made me think, "this htmx sounds interesting, I should check it out".

[sergiotapia]

I completely agree with the author that AI has problems with more niche language/frameworks.

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.

[valcron1000]

> complex forms with dynamic validation and conditional fields

So 99% of the production sites out there. Good thing I didn't invest into htmx when it was the flavor of the month.

[PaulHoule]

I have a system I’m working on that is all HTMX but I am thinking about options.

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.

[WickyNilliams]

Could you not have

    ?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 complex