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

131–140 of 216 posts

Re: Why Gumroad Didn't Choose Htmx

#131

Post by d13 »

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.

Re: Why Gumroad Didn't Choose Htmx

#132

Post by pier25 »

yarg wrote: post #88
pier25 wrote: post #82

Earlier quoted context omitted.

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.

The point I'm contesting is that it's more difficult to validate on the server using HTMX.

And I'm not saying you should be only validating on submit when using HTMX.

Client exclusive validation is quite limited. Very often you need a trip to the server anyway so I don't buy the latency argument.

Plus in most cases showing error messages too fast is terrible UX. The only exception I can think of is when checking the validity of a password.

Re: Why Gumroad Didn't Choose Htmx

#133

Post by pier25 »

code_biologist wrote: post #100
pier25 wrote: post #82

Earlier quoted context omitted.

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?

Validating in multiple places doesn't mean 2x the code. You can validate on both the client and the server using the same code. One of the charms of server-side JS.

Yes, in some cases when you don't need a trip to the server. But you're also bloating the client for no great benefit.

Re: Why Gumroad Didn't Choose Htmx

#134

Post by tomcam »

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.

> I have been looking for a thoughtful negative experience with htmx to host on the htmx website

Mad props, my man. I love that attitude. To me it's making the world a better place in a tangible way.

Re: Why Gumroad Didn't Choose Htmx

#135

Post by lifeisstillgood »

The interesting one is “lack of AI support” - in other words chatGPT not being able to churn out example code is a strategic disadvantage these days!

I do wonder how you can feed your docs to the maw of the AI machine? Can you tell if they scraped your docs?

Re: Why Gumroad Didn't Choose Htmx

#136

Post by endemic »

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…

Yeah, it seemed from the description of desired functionality that heavy JS was going to be a necessity.

Re: Why Gumroad Didn't Choose Htmx

#137

Post by breuleux »

ryanchants wrote: post #29
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 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…

It would be nice if some AI tools could be developed to actually evaluate new libraries and frameworks. For instance, if there are already 10 libraries to do something and I develop a new one that's objectively faster than all of them (true story), could some AI do the work of installing and benchmarking it and incorporate the results in its knowledge base? And periodically update it? Is there any way to leverage AI for discovery of solid code? I suspect this is beyond current capabilities, but one can dream.

Re: Why Gumroad Didn't Choose Htmx

#138

Post by Aeolun »

rikthevik wrote: post #115
x0x0 wrote: post #89

Earlier quoted context omitted.

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.

The more I work with React, the more I realize I just don’t have the motivation to learn and keep up with more than one way of doing front-end. Using it everywhere is working out pretty well for me.

Sometimes it’s not the best choice for the app I’m working on, but it’s always thr best choice for me.

Re: Why Gumroad Didn't Choose Htmx

#139

Post by BestHackerOnHN »

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…

> It's refreshing to see this compared to lots of other projects that always seem to claim to be the best solution for everything.

Agreed 100%, hencq!

Re: Why Gumroad Didn't Choose Htmx

#140

Post by throwitaway1123 »

pier25 wrote: post #132
yarg wrote: post #88

Earlier quoted context omitted.

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.

The point I'm contesting is that it's more difficult to validate on the server using HTMX. And I'm not saying you should be only validating on submit when using HTMX. Client exclusive validation is quite limited. Very often you need a trip to the server anyway so I don't buy the latency argument. Plus in most cases showing error messages too fast is terrible UX. The only exception I can think of is when checking the…

> Plus in most cases showing error messages too fast is terrible UX.

The solution to that problem is to debounce or throttle your error messages. That allows you to report validation issues to the user quickly, but not overwhelmingly fast, before sending a network request potentially across the Earth and back.

Post reply on HN