Live data from Hacker News

Why Gumroad Didn't Choose Htmx

htmx.org

111–120 of 216 posts

Re: Why Gumroad Didn't Choose Htmx

#111
post #72

Earlier quoted context omitted.

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

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.

Re: Why Gumroad Didn't Choose Htmx

#114
post #92

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 so much, I am a user since intercooler.

based, thank you

Re: Why Gumroad Didn't Choose Htmx

#115
post #89
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 used hotwire a bunch, and with minor differences, I think the list of things that htmx is not good for is spot on. I don't think I'm explaining this well, but maybe this will help someone: Hotwire / htmx are about server-side rendering and making that work more smoothly with the client. eg fewer page navigations, more rapid update of the client, etc. But it's still, through and through, server render with server…

> 95% of your project even if the main interaction loop is done in react

The trick is to be very honest with yourself (and team) about how much complex front-end UI the application actually _requires_. Using React where it isn't necessary is very expensive in the long run. The older I get, the more the grug brained developer makes sense.

Re: Why Gumroad Didn't Choose Htmx

#116
post #46

Earlier quoted context omitted.

Exactly. I’m a big htmx fan, but I think this post displays some serious lack of technical awareness from the author. More like they wanted to try out HTMX based on vibes as opposed to its actual strengths and weaknesses which would be apparent to anyone with even a cursory knowledge of the web platform and the docs on htmx.org

It sounds to me like they shared a learning experience.

Yeah, without having the foresight to know that Hacker News would come after them with very disingenuous interpretations of what they’ve shared, because HN commenters are so used to spending all their days having internet arguments that they take everyone as a personal attack.

Nothing in this post indicates that the author doesn’t know any of what all these people in the peanut gallery are snarkily lecturing about, FFS. Working in the open must be so difficult.

Re: Why Gumroad Didn't Choose Htmx

#117

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

It’s kind of a nice compliment to all of the “we converted our react app to htmx and everything is so much better” articles written by people who probably shouldn’t have used react to begin with.

Re: Why Gumroad Didn't Choose Htmx

#118

Earlier quoted context omitted.

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

I still think it's a perfectly fine productivity multiplier to use as long as you still understand what you're doing.

There's a very clear skill ceiling on the kind of code for which LLMs can serve as a productivity multiplier.

Re: Why Gumroad Didn't Choose Htmx

#119
post #101

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

I would say React is (so much) better because it's functional, immutable, one-way, almost declarative. In comparison, stuff like ActiveRecord is very imperative, shared-mutable-state thing. For React-based code you usually take a language with a rich static type system (TS); Rails with its design-by-contract struggled to provide type signatures, last time I checked.

One of them is much easier to reason about than the other, even though the other is enviably compact.

Re: Why Gumroad Didn't Choose Htmx

#120
post #104

Earlier quoted context omitted.

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?

Indeed. Even if hn were a monolith and all had the same opinion, it certainly would not be a pro PHP, Java and MySQL position.
Post reply on HN