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

151–160 of 216 posts

Re: Why Gumroad Didn't Choose Htmx

#151

Post by emseetech »

jonathan-adly wrote: post #27
fsndz wrote: post #16

I will start using htmx as soon as there is a 20K MRR startup built only with it.

My startup using htmx was there - and it was acquired successfully. They migrated pretty quick to react after the acquisition due to team dynamics (offshore big teams - seeped into JS heavy client, thin server culture). htmx was a struggle there as well. It worked amazing for us as a small team where everyone was full stack and I always build using htmx-first now. But, it is a struggle for folks who have been working…

| They migrated pretty quick to react

One advantage of htmx (along with web components and standard html+css) is that migrating to anything else is much easier than the other way around. A rewrite from an htmx app to a React app can be trivial. A rewrite from React to anything else will not be.

Re: Why Gumroad Didn't Choose Htmx

#152

Post by recursivedoubts »

mthoms wrote: post #145
recursivedoubts wrote: post #44

Earlier quoted context omitted.

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…

Does it support nesting?

here htmx is integrating with Sortable.js for drag and drop functionality via events, so whatever Sortable can do, htmx can respond to:

http://sortablejs.github.io/Sortable/

Re: Why Gumroad Didn't Choose Htmx

#153

Post by azemetre »

internetter wrote: post #141
rmbyrro wrote: post #74

Earlier quoted context omitted.

In my experience, ChatGPT and Github Copilot are significantly worse at htmx compared to mainstream tech. They hallucinate A LOT more.

When this happens for me with Copilot, I increase the context by opening other files, and then it works fine.

How does this work in copilot if you use the neovim plugin? Open lots of buffers?

Re: Why Gumroad Didn't Choose Htmx

#154

Post by bitbasher »

It's nice to see experiences using htmx (both positive and negative). However, it's hard to ignore how much misunderstanding there seems to have been when using it.

There's no rule that says everything needs to go to the server and back when using htmx. You don't have to _not do_ client side scripting. There's a whole section in the hypermedia book based on client side scripting. This is why most people using htmx are also pairing it with a light library for client interactions (alpine, hyperscript, web components, etc). Heck-- you can even pair it with react or any of the other heavier libraries.

Re: Why Gumroad Didn't Choose Htmx

#156

Post by chrisco255 »

meerab wrote: post #79

"The development process felt natural with Next.js" - the author What part of this ReactJS syntax you find natural? Familiar Yes, Natural NO. useEffect(() => { const timer = setInterval(() => { setCount((prevCount) => prevCount + 1); }, 1000); return () => clearInterval(timer); }, []);

HTMX doesn't have an elegant solution for timers and intervals, as far as I know. You would still need to awkwardly wire that up in JS with HTMX.

Re: Why Gumroad Didn't Choose Htmx

#157

Post by chrisco255 »

righthand wrote: post #86

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

You can self-host Next.js. There's no dependency on Vercel.

Re: Why Gumroad Didn't Choose Htmx

#158

Post by killerstorm »

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…

In my experience LLMs are good at picking up syntax from the context.

Recently I used Cursor with an in-house developed language and it was able to get almost perfect completions upon seeing ~100 lines of context.

Not all LLMs are equally good at this: Gemini seems to be particularly resistant to adapting to a new syntax

Re: Why Gumroad Didn't Choose Htmx

#159

Post by spirobelv2 »

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…

after having used both: sortablejs is better than reactdnd.

that being said: htmx makes it too hard to quickly add a fat frontend to a page when necessary. The points about the react ecosystem are very valid, even if drag and drop is an exception. The network effects of react and others are hard to beat. Its probably even more npm as a whole than just react.

wrote myself a framework with bun that solves this for me: https://github.com/spirobel/mininext

still get the pure html+css feeling like with htmx, but can throw in a big frontend when needed.

https://x.com/spirobel/status/1827231794934247674?t=moRzsWIP...

Re: Why Gumroad Didn't Choose Htmx

#160

Post by nsonha »

simonw wrote: post #13
nsonha wrote: post #9

Comparing it with React is a low bar, since a lot of people are unhappy with React. Arguments like "React is popular, AI knows it", or "React is popular, lots of component have been written in it" seem weak. A proper antithesis for htmlx should compares it with SPA.

HTMX can be used as a tool for building SPAs, so I don't think it makes sense to compare it with SPA. What's an SPA if not a single web page where clicking on things causes that UI to update in-place in different ways?

htmlx is what you would have on the front end when you do server rendering. Server has to do quite a bit, routing among other things.

In SPA server just serves a single page and routing is all done in the client.

Post reply on HN