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

121–130 of 216 posts

Re: Why Gumroad Didn't Choose Htmx

#121

Post by freedomben »

nine_k wrote: post #119
ksec wrote: post #101

Earlier quoted context omitted.

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

React is a client-side library. Rails is a server-side framework. I don't see how you can even really compare these apples and oranges.

Personally, I think rails and react go together very well. For apps that need rich client-side functionality, I will do a react spa with a back end in elixir/ Phoenix (which is very similar to rails).

For apps that don't, just doing server-side rendering is plenty sufficient and is my preference.

Re: Why Gumroad Didn't Choose Htmx

#122

Post by hencq »

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…

Thanks! That actually seems very smooth. Trying out htmx has been high on my list for a while when I finally get time to do a little personal side project. Real life keeps getting in the way, but this is a good nudge. The appealing thing about htmx to me is that it seems like it should be very easy to keep everything in your head.

Re: Why Gumroad Didn't Choose Htmx

#123

Post by hakunin »

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 careers. That said, I get the value of off-the-shelf React components, and ease of finding docs/help, so wouldn't discount that anyway.

Re: Why Gumroad Didn't Choose Htmx

#124

Post by wwarner »

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…

respectfully disagree. i think that the value of llm suggestions are driving us toward a kind of standardization that is really good. we'll all be java programmers soon!

Re: Why Gumroad Didn't Choose Htmx

#125

Post by nine_k »

freedomben wrote: post #121
nine_k wrote: post #119

Earlier quoted context omitted.

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…

React is a client-side library. Rails is a server-side framework. I don't see how you can even really compare these apples and oranges. Personally, I think rails and react go together very well. For apps that need rich client-side functionality, I will do a react spa with a back end in elixir/ Phoenix (which is very similar to rails). For apps that don't, just doing server-side rendering is plenty sufficient and is m…

I'm only comparing development experience and, so to say, the conceptual environment.

Verily, Rails can be a pretty good and compact way to serve backend APIs for a React-based frontend. But the API boundary is the "narrow waist", its relative neutrality allows to switch backend and frontend implementations easily, or even to mix them. I've seen a React frontend seamlessly consuming APIs served by Python and Rust services, and it's hardly possible to spot which endpoint is served by what in the frontend code.

Unlike on the frontend, FP approaches on the backend are not (as) widespread. Established imperative frameworks (Django, Rails, Spring Boot, etc) are still the huge majority.

Re: Why Gumroad Didn't Choose Htmx

#126

Post by markmark »

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…

The AI and Tooling support point is really just an extension of the Community and Ecosystem point. Even before LLMs React had an advantage in that every question you had was probably already on StackOverflow and there are mature React libraries for almost everything. Now some people might use an LLM to answer the question they previously would have gone to StackOverflow for but the outcome is the same: there are advantages to using what other people are using.

Re: Why Gumroad Didn't Choose Htmx

#127

Post by dannyobrien »

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.

Me neither. In the 2000s, Tor did something similar (a "what Tor can't do" page) and prominent linked to it on the front page, which definitely improved the project's reputation with a coterie of infosec professionals.

It might not have helped with wider adoption though. People would send me the link saying "Look at all of these bad things about Tor", and it would be links to Tor explanatory pages.

It was around that time that I realised that when trying to give people an intuition for what software many Internet professionals trust, the list of "green flags" I identified was, in fact, the exact opposite of what the majority might guess as being good signs. "Large list of attractive sounding features" vs "Lists problems with the tool as prominently as benefits" ; "Sold and marketed by a large well-known company" vs "Developed by a small, volunteer team" ; "Free to download" vs "Costs money"; "Modern, professionally-designed website" vs "Looks like it was built in 1997", etc, etc.

Re: Why Gumroad Didn't Choose Htmx

#128

Post by deciduously »

rmbyrro wrote: post #73
dakiol wrote: post #48

Earlier quoted context omitted.

Is it just me or the article smells like AI-generated?

Your AI smell sensors need more training data to reduce hallucinations.

It's a safe comment for people, generally, to call out any snippet of text as AI. If they're right, they get to feel smug about being right, and if they're wrong, they get to feel smug about telling someone their thing was bad and they should feel bad. I'm no fan of AI slop either, but calling out text for which you have no way to determine the provenance as auto-generated is, in my opinion, also "slop".

Re: Why Gumroad Didn't Choose Htmx

#129

Post by aidenn0 »

ksec wrote: post #101
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.

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

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

Perhaps he meant Next.js? TFA mentions they are using Next.js

Post reply on HN