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

141–150 of 216 posts

Re: Why Gumroad Didn't Choose Htmx

#141

Post by internetter »

rmbyrro wrote: post #74
spankalee wrote: post #63

Earlier quoted context omitted.

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.

When this happens for me with Copilot, I increase the context by opening other files, and then it works fine.

Re: Why Gumroad Didn't Choose Htmx

#142

Post by recursivedoubts »

d13 wrote: post #131
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.

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.

get the mug!

https://swag.htmx.org/products/htmx-sucks-mug

Re: Why Gumroad Didn't Choose Htmx

#143

Post by cxr »

DevX101 wrote: post #72
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…

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

Which is exactly what shouldn't happen. Every serious proposal/RFC needs to have an honest stab at what the competition looks like and why it won't work there.

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

Re: Why Gumroad Didn't Choose Htmx

#144

Post by AlienRobot »

codazoda wrote: post #108
skydhash wrote: post #80

Earlier quoted context omitted.

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

It looks like the sticky header with "Add to cart" disappears when the large "add to cart" button scrolls into view, and reappears when that disappears.

Re: Why Gumroad Didn't Choose Htmx

#145

Post by mthoms »

recursivedoubts wrote: post #44
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…

There is an htmx demo on drag-and-drop (in the reorder sense) using Sortable.js here: 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…

Does it support nesting?

Re: Why Gumroad Didn't Choose Htmx

#146

Post by jgalt212 »

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

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.

Re: Why Gumroad Didn't Choose Htmx

#147

Post by jboogie77 »

mattrighetti wrote: post #36

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

I had the same exact thought. The project scope was not “simple” at all and I personally would have jumped straight to react for this.

Re: Why Gumroad Didn't Choose Htmx

#148

Post by createaccount99 »

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…

> the bless of MVC apps.

haha, good one

Re: Why Gumroad Didn't Choose Htmx

#149

Post by emseetech »

hakunin wrote: post #123

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

Not just the devs, but this is a great example of UX designers "thinking in React" which I believe is the biggest barrier to adoption for htmx. We've had a generation of designers who design mobile and web very similarly, and offload the complexity of implementing that onto the developers.

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.

Re: Why Gumroad Didn't Choose Htmx

#150

Post by giraffe_lady »

recursivedoubts wrote: post #111
giraffe_lady wrote: post #87

Earlier quoted context omitted.

It's not quite the same but SQLite has a page where they clearly present its limitations and how to identify the situations where you should choose something else. https://www.sqlite.org/whentouse.html

We have a similar essay up on when to use htmx/hypermedia: 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.

Ah cool! I've used htmx and like it but I hadn't seen this before.
Post reply on HN