Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Gumroad Didn't Choose Htmx

htmx.org

Post reply on HN
Print view View original

71–80 of 216 posts

Re: Why Gumroad Didn't Choose Htmx

#71

Post by mattgreenrocks »

treyd wrote: post #50
ryanchants wrote: post #29

Earlier quoted context omitted.

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…

The problem is that for most domains our hammers are still pretty bad.

Agree. A lot of the most popular libraries/frameworks are not necessarily the best. Removing more fitness checks will only worsen this problem.

Re: Why Gumroad Didn't Choose Htmx

#72

Post by DevX101 »

hencq wrote: post #30
recursivedoubts wrote: post #14

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.

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…

I've never seen a project highlight a negative use case in detail. This is a first.

Re: Why Gumroad Didn't Choose Htmx

#73

Post by rmbyrro »

dakiol wrote: post #48
recursivedoubts wrote: post #14

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.

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

Your AI smell sensors need more training data to reduce hallucinations.

Re: Why Gumroad Didn't Choose Htmx

#74

Post by rmbyrro »

spankalee wrote: post #63
ketzo wrote: post #20

> 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'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 p…

In my experience, ChatGPT and Github Copilot are significantly worse at htmx compared to mainstream tech. They hallucinate A LOT more.

Re: Why Gumroad Didn't Choose Htmx

#75

Post by sergiotapia »

arrowsmith wrote: post #67
sergiotapia wrote: post #55

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, sugg…

Which AI are you using for Elixir/Phoenix? I find that ChatGPT is as you describe for Elixir, but Claude writes Elixir very well.

I only use claude sonnet 3.5 for code, it was the last leap before ai llms become useful for coding for me. it's all butter moving forward!

Re: Why Gumroad Didn't Choose Htmx

#76

Post by tuyiown »

recursivedoubts wrote: post #14

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.

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.

Re: Why Gumroad Didn't Choose Htmx

#77

Post by alexpetros »

ketzo wrote: post #20

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

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

Re: Why Gumroad Didn't Choose Htmx

#78

Post by ffsm8 »

spankalee wrote: post #63
ketzo wrote: post #20

> 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'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 p…

> they do a pretty great job of generating good niche framework code.

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.

Re: Why Gumroad Didn't Choose Htmx

#79

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

Re: Why Gumroad Didn't Choose Htmx

#80

Post by skydhash »

simonw wrote: post #15

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

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.
Post reply on HN