Live data from Hacker News

Why Gumroad Didn't Choose Htmx

htmx.org

171–180 of 216 posts

Re: Why Gumroad Didn't Choose Htmx

#171

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.

htmx is really just html on steroids, it's not a replacement for any JS library

Re: Why Gumroad Didn't Choose Htmx

#172

> complex forms with dynamic validation and conditional fields So 99% of the production sites out there. Good thing I didn't invest into htmx when it was the flavor of the month.

Seems to me all validation, simple or dynamic, should be handled server side. And once you implement that, server rendering of conditional fields is free.

Feel free to pass on htmx but don't convince yourself that it can't handle "complex forms" because this particular group of knuckleheads preferred React.

Re: Why Gumroad Didn't Choose Htmx

#173
post #132
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…

Showing error messages on the client side is not too fast or bad UX. Let's say someone entered an invalid credit card. Or an invalid email. Why even let that touch the backend?

Note that frontend forms libraries allow a lot of choice over when to show error messages.

Re: Why Gumroad Didn't Choose Htmx

#174
Another false dichotomy is server rendered vs single page app, when the happy place is both. One builds a bundle to embed in a server rendered page, as distinct from other bundles served up with other distinct pages. Ones rollup file would have an array of build objects, input output params. The user doesn't have to wait an eternity to download a monolithic single page app bundle. One doesn't get brain damaged by trying to maintain a monolithic state in a giant monolithic blob of javascript, urls work again, routing is returned to the server, and you could use a different framework on each page if you want to, thats how little it matters at that point.

Why is no one mentioning embedding a js bundle in an htmx rendered page?

Re: Why Gumroad Didn't Choose Htmx

#175
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); }, []);

You're being very generous with this code sample. It can get far more complex if you want a custom hook with variable timeout. Dan even had to write a lengthy article on the topic. https://overreacted.io/making-setinterval-declarative-with-r...

Re: Why Gumroad Didn't Choose Htmx

#176

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…

Could you not have

    ?query={entire query goes here}
Rather than splitting it up into multiple query params? Feels like it's one indivisible param rather than multiple facets. You could always base64 encode if it starts getting complex

Re: Why Gumroad Didn't Choose Htmx

#177
post #131

Earlier quoted context omitted.

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.

get the mug! https://swag.htmx.org/products/htmx-sucks-mug

Awesome, thanks!!

Re: Why Gumroad Didn't Choose Htmx

#178
post #170

Earlier quoted context omitted.

> 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 think ~0% of people will be coding without LLMs in some form in a few years. How many people are still coding in assembler?

The LLMs will need to get a lot better though. I see every day on reddit/X a bunch of people saying they downloaded Cursor and built a saas without ever having coded anything in their lives; the resulting code is always terrible, full with really obvious bugs and buckets of trivial security issues. All these things can be prevented, in theory, but current LLMs really don't do that at all (they aren't capable).

Re: Why Gumroad Didn't Choose Htmx

#179

Earlier quoted context omitted.

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

Yes. And no matter how good LLMs get at coding there will always be a crowd intentionally doing it themselves, especially in the open source arena, if only just to keep the joy alive.

I fully expect to keep writing code for decades, just like I still use a hand plane and enjoy growing plants to eat.

I know other methods are more efficient. But I’m here to experience life. I want to do the hard things. I want to be uncertain, confused, to make mistakes, and to learn.

AI is a neat tool in limited scopes. Every time I use it though, I feel like I didn’t get the full experience. I’m acutely aware of all the rabbit holes I missed, or the tiny details I’d notice along the way and helpfully remember 10 years later. For everything it adds, it takes at least as much away from where I’m looking. And I like those parts.

Re: Why Gumroad Didn't Choose Htmx

#180
post #170

Earlier quoted context omitted.

I think ~0% of people will be coding without LLMs in some form in a few years. How many people are still coding in assembler?

The LLMs will need to get a lot better though. I see every day on reddit/X a bunch of people saying they downloaded Cursor and built a saas without ever having coded anything in their lives; the resulting code is always terrible, full with really obvious bugs and buckets of trivial security issues. All these things can be prevented, in theory, but current LLMs really don't do that at all (they aren't capable).

All of these SaaS products are also clones of things people have already made. If it was helping newcomers create novel things from great imaginations and curiosity, I’d be really excited about this. Instead I saw a reminder app, a todo app, a combination of these, and a voice transcription app.

All of these have existed in huge numbers for a decade or close to it. This isn’t interesting. It wouldn’t have taken much to do this without AI if these people found motivation through some other means. Nothing notable is happening yet.

Post reply on HN