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

81–90 of 216 posts

Re: Why Gumroad Didn't Choose Htmx

#81

Post by gen220 »

smallerfish wrote: post #2

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

Yeah, I've been using HTMX with UIKit components. Having a modern, stateful, and dynamic website is definitely not incompatible with HTMX.

Re: Why Gumroad Didn't Choose Htmx

#82

Post by pier25 »

mplewis wrote: post #19
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?"

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

What's the difference?

You can split the validation in multiple functions/modules which you can then use both at submission or per step/page.

Also, it seems you're implying having two validation systems (on the client and server) is actually good?

Re: Why Gumroad Didn't Choose Htmx

#83

Post by maicro »

Off-topic except that it's about gumroad - does anyone know of a proper abuse submission address or form for gumroad?

I've received two spam emails from them in the past week, where a seller "sold" me something for $0, with a cryptocurrency scam in the item description - so I received an email from a legit gumroad address, but with attacker-provided content (text only in the email at least).

I submitted one through their form, but it's a Google Forms page configured to only allow a single response, so I could only submit once. I also forwarded one to "abuse@gumroad.com", but no clue if that's a real destination or the best place for it...

Gmail flagged both of these as Spam, so while I'm not really concerned about my own security here, I figure gumroad themselves would at least like to know about this so they can limit the (spam list) reputation hit...

Re: Why Gumroad Didn't Choose Htmx

#84

Post by skydhash »

freeone3000 wrote: post #59
riffraff wrote: post #39

Earlier quoted context omitted.

I don't think convention over configuration causes LLMs any problems, GitHub copilot generates code matching rails conventions quite easily for example.

Because there’s enough rails code in the training data to determine the proper conventions :) if you’re making something new without this glut of data, it’s going to be much more difficult for a coding assistant to match a convention it’s never seem before.

The thing is, with some elbow grease, you can write a great plugin for your preferred editor. No need for dubious LLMs results, especially when the difficult part, code intellisense, is already solved with LSP. If you're a shop that has invested in a framework, it would be cheaper and more productive.

Re: Why Gumroad Didn't Choose Htmx

#85

Post by jimmaswell »

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.

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

Re: Why Gumroad Didn't Choose Htmx

#86

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

Re: Why Gumroad Didn't Choose Htmx

#87

Post by giraffe_lady »

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.

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

Re: Why Gumroad Didn't Choose Htmx

#88

Post by yarg »

pier25 wrote: post #82
mplewis wrote: post #19

Earlier quoted context omitted.

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

What's the difference? You can split the validation in multiple functions/modules which you can then use both at submission or per step/page. Also, it seems you're implying having two validation systems (on the client and server) is actually good?

Yes?

You want to validate on the client side because it reduces latency and improves responsiveness.

You want to validate on the server side because you cannot trust the fucking client.

Re: Why Gumroad Didn't Choose Htmx

#89

Post by x0x0 »

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

It works well as long as the server is always the source of truth. The things that it isn't good at, such as drag and drop or complex, multi-state forms on the client side, are basically because you temporarily have a split source of truth: the client is the source of truth with complex state.

That said, my strong suggestion would be to use Hotwire or htmx for 95% of your project even if the main interaction loop is done in react. Your app will still likely have tons of crud around user management, settings / config, onboarding, etc. You can make all that work more nicely.

edit: in case it wasn't clear: for the things that are in the hotwire/htmx wheelhouse, the tech works really well. It's a fantastic improvement.

Re: Why Gumroad Didn't Choose Htmx

#90

Post by exabrial »

>Scalability Concerns: As our project grew in complexity, we found htmx struggling to keep up with our needs

A Haiku on the above, oft-repeated, sexy-problem-to-have:

Everyone says this,

but nobody has benchmarks,

because its not real

You are not Google,

but make believe problems,

Are the most fun ones!

Post reply on HN