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

91–100 of 216 posts

Re: Why Gumroad Didn't Choose Htmx

#91

Post by SrslyJosh »

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?

Re: Why Gumroad Didn't Choose Htmx

#92

Post by n3storm »

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

Re: Why Gumroad Didn't Choose Htmx

#93

Post by tom85 »

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?

Maybe they are just faster with AI.

Re: Why Gumroad Didn't Choose Htmx

#94

Post by Shawnecy »

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?

I don't think it's so split between they can and can't. It's probably more about how it impacts velocity.

Re: Why Gumroad Didn't Choose Htmx

#95

Post by SrslyJosh »

> UX Limitations: htmx ended up pushing our app towards a Rails/CRUD approach, which led to a really poor (or at least, boring and generic) user experience by default.

Good websites behave in predictable ways. If I can tell your website is using fucktons of javascript, I'm probably not enjoying using it. (And calling it an "app" is a bit of a red flag for bad UX to me.)

Re: Why Gumroad Didn't Choose Htmx

#96

Post by Freedom2 »

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…

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.

Re: Why Gumroad Didn't Choose Htmx

#98

Post by PaulHoule »

I have a system I’m working on that is all HTMX but I am thinking about options.

The system is a document management tool which can be configured to be a lot of different things like an image sorter or an RSS reader or an information extraction tool. The key design point is that it has to be easily configurable.

I worked on a similar system at a startup that used an SPA and boy was it a bear because changing anything involved making both front end and back end changes. We had to change directions all the time to keep up with our customers and the monolithic SPA sure slowed us down.

My current back end has a query builder that can generate queries with a complex structure as is supported by OWL DL, like

    (Temp > 95 AND Temp
but with HTMX I can best use URL query parameters like

    ?temp:gt=95&temp:lt=100
that are all ANDed. I am thinking about making little applets with svelte that could do what HTMX can’t.

Re: Why Gumroad Didn't Choose Htmx

#99

Post by pseudosavant »

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.

Much respect for showing where htmx might not be as suitable as other tools. In my mind htmx is more a replacement for jQuery than React. htmx and jQuery both augment documents with interaction. React tries to be the entire document. Different tools for different jobs.

Re: Why Gumroad Didn't Choose Htmx

#100

Post by code_biologist »

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?

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.
Post reply on HN