Why Gumroad Didn't Choose Htmx • Hacker News Board

Re: Why Gumroad Didn't Choose Htmx

#101

Post by ksec » Thu, Oct 03, 2024, 9:39 PM UTC

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.

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

Re: Why Gumroad Didn't Choose Htmx

#102

Post by jmull » Thu, Oct 03, 2024, 9:40 PM UTC

OK, hats off to htmx for posting/hosting this.

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.

Re: Why Gumroad Didn't Choose Htmx

#103

Post by cheema33 » Thu, Oct 03, 2024, 9:41 PM UTC

SrslyJosh wrote: post #91

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…

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

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

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.

Re: Why Gumroad Didn't Choose Htmx

#104

Post by ksec » Thu, Oct 03, 2024, 9:45 PM UTC

Freedom2 wrote: post #96

hencq wrote: post #30

Earlier quoted context omitted.

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…

Agreed. Too often you'll see HN's claim that PHP / Java / MySQL are the best choices for everything, where often times they are blind to specific problems and use-cases that other developers are trying to solve.

>Too often you'll see HN's claim that PHP / Java / MySQL are the best choices for everything.

Either this is missing /s or this is trolling, right?

Re: Why Gumroad Didn't Choose Htmx

#105

Post by fsndz » Thu, Oct 03, 2024, 9:46 PM UTC

jonathan-adly wrote: post #27

fsndz wrote: post #16

I will start using htmx as soon as there is a 20K MRR startup built only with it.

My startup using htmx was there - and it was acquired successfully. 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…

convenient. I would have liked taking a look at your apps built only using htmx

Re: Why Gumroad Didn't Choose Htmx

#106

Post by fsndz » Thu, Oct 03, 2024, 9:55 PM UTC

learnedbytes wrote: post #42

fsndz wrote: post #16

I will start using htmx as soon as there is a 20K MRR startup built only with it.

The difference between a 20k MRR startup and lower will almost certainly not be because of HMTX.

this is true in theory but not in practice. just read the article, they came up to the same conclusion. if you want to offer a slick UX (a key element to convince users to pay these days) htmx won't cut it.

Re: Why Gumroad Didn't Choose Htmx

#107

Post by gumbul » Thu, Oct 03, 2024, 9:55 PM UTC

shortrounddev2 wrote: post #18

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

The uncle who wrote the tool is probably a friend of the moderators here. He thinks that changing the texts in the element with a few xhr functions is a great success. I've seen very few guys as weird as this guy.

Re: Why Gumroad Didn't Choose Htmx

#108

Post by codazoda » Thu, Oct 03, 2024, 9:59 PM UTC

skydhash wrote: post #80

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.

I just looked at this iPhone alarm clock on Gum Road, which I also read about on HN. The page describing the clock is janky. Slowly scroll down the page (with a track pad) and it will jump up and down erratically as you get past the "Add to Cart" button. Hover your mouse in one vertical position on the page and it will turn the header on and off over and over again.

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.

Re: Why Gumroad Didn't Choose Htmx

#109

Post by MetaWhirledPeas » Thu, Oct 03, 2024, 9:59 PM UTC

alexpetros wrote: post #77

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.

Yes. And no matter how good LLMs get at coding there will always be a crowd intentionally doing it themselves, especially in the open source arena, if only just to keep the joy alive.

Re: Why Gumroad Didn't Choose Htmx

#110

Post by johannes1234321 » Thu, Oct 03, 2024, 10:05 PM UTC

SrslyJosh wrote: post #91

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…

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

It's not about "being able" it is about being efficient. There are many cases where current AI can provide boilerplate and good examples for doing something specific, which eases things a lot.

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.