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

201–210 of 216 posts

Re: Why Gumroad Didn't Choose Htmx

#201

Post by steve_adams_86 »

anonzzzies wrote: post #182
steve_adams_86 wrote: post #180

Earlier quoted context omitted.

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…

> All of these have existed in huge numbers for a decade or close to it That doesn't always matter though; I saw some guy on reddit selling 1000s of subs of a server uptime page they generated with an LLM (Cursor I think it was). Most do it for the money and that is working IF you have the following somewhere.

Do you have a link to that?

Re: Why Gumroad Didn't Choose Htmx

#202

Post by abrookewood »

recursivedoubts wrote: post #111
giraffe_lady wrote: post #87

Earlier quoted context omitted.

It's not quite the same but SQLite has a page where they clearly present its limitations and how to identify the situations where you should choose something else. https://www.sqlite.org/whentouse.html

We have a similar essay up on when to use htmx/hypermedia: https://htmx.org/essays/when-to-use-hypermedia/ I think it's a good idea for any software project to have something like this so that people know when it's a good fit and when it isn't.

Have to agree - it's certainly refreshing to see someone acknowledging that their technology isn't going to work best in every case.

Re: Why Gumroad Didn't Choose Htmx

#203

Post by yawaramin »

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.

Those charms can turn tiresome rather quickly once you discover those server-side JS libraries you're popping like candies are adding bloat and security vulnerabilities once they're shipped to the client side.

Re: Why Gumroad Didn't Choose Htmx

#204

Post by smabie »

bccdee wrote: post #199
cheema33 wrote: post #103

Earlier quoted context omitted.

> If your devs can't work without something writing their code for them, why are you hiring them? I am currently in the process of hiring a backend engineer. Anybody who does not use AI to aid development work gets an automatic disqualification. In my experience, a good engineer using AI tools will run circles around a good engineer not using AI tools.

"A good cyclist using training wheels will go circles around a good cyclist who doesn't." No, training wheels only help bad cyclists. You can't generalize that and assume they will make a good cyclist even better. AIs generate deeply mediocre code. This is better than anything a person who can't code on their own would produce, but an experienced developer will have to spend all their time babysitting the AI to get i…

Turns out mediocre code is fine most of the time though

Re: Why Gumroad Didn't Choose Htmx

#205

Post by chrisco255 »

syndicatedjelly wrote: post #167
chrisco255 wrote: post #157

Earlier quoted context omitted.

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

It is a righteous pain in the ass to do so. There is no "dependency" on Vercel, but the choice is to either build your castle in someone else kingdom, or build all the infrastructure and plumbing on your own land and "self-host". The point is, it could be a whole lot easier to self-host Next.js. There's a reason it's not.

It's not at all difficult to self host Next.js. First of all, you can use Next to compile a static site that can be deployed anywhere. You can also run it in Docker or outright by simply: `npm run build` && `npm run start`

Re: Why Gumroad Didn't Choose Htmx

#206

Post by chrisco255 »

syndicatedjelly wrote: post #166
chrisco255 wrote: post #156

Earlier quoted context omitted.

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.

It does, `hx-trigger` supports repeated polling on an interval and delays. The terminology is different, the ergonomics are different but the underlying concept is the same.

hx-trigger is used for server side requests. `setInterval` can be used to fire http requests on an interval but it can also be used for a lot more things and you have full control over it. `hx-trigger` involves using proprietary language as strings to program the request. I have no idea by looking at that how it tears down, cancels, or responds to other events or triggers on the page. The reason for JSX is a custom template language ALWAYS ends up reinventing JavaScript in a worse, more limited form as template strings.

Re: Why Gumroad Didn't Choose Htmx

#207

Post by recursivedoubts »

gumbul wrote: post #107
shortrounddev2 wrote: post #18

I literally only ever hear about htmx from YC. I still don't know what the point of it is, it seems like one of those opinionated programmer things like "I don't use a framework" or "you don't need javascript to make my site work"

The uncle who wrote the tool is probably a friend of the moderators here. He thinks that changing the texts in the element with a few xhr functions is a great success. I've seen very few guys as weird as this guy.

* father

Re: Why Gumroad Didn't Choose Htmx

#208

Post by insidstwr »

WD-42 wrote: post #52
jonathan-adly wrote: post #27

Earlier quoted context omitted.

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…

Kinda wild that there is an entire generation of web devs for whom server side rendering is actually the new, strange thing.

Ssr is really about React. Rendering referring to HTML generation using react.

Probably the old school thing is "serving a page"

Re: Why Gumroad Didn't Choose Htmx

#209

Post by insidstwr »

fsndz wrote: post #106
learnedbytes wrote: post #42

Earlier quoted context omitted.

The difference between a 20k MRR startup and lower will almost certainly not be because of HMTX.

this is true in theory but not in practice. just read the article, they came up to the same conclusion. if you want to offer a slick UX (a key element to convince users to pay these days) htmx won't cut it.

Fast is underrated these days and the experience of a fast site TTFB, FCP etc then being more bare metal and eschewing frameworks is wise. Ditching NextJS for Django allowed me to heavily speed up a site. You can do tricks to get React to be fast but that is more work.

Fast impresses people. Too many sites are janky and slow.

Re: Why Gumroad Didn't Choose Htmx

#210

Post by Izkata »

PaulHoule wrote: post #187
WickyNilliams wrote: post #176

Earlier quoted context omitted.

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

If it just comes to having buttons to add and remove tags I guess the server could generate those packed query strings (that HTMX will GET or POST to) Full text fields would be harder as the front end is going to want to put them in their own query parameter although one attack on the problem is to have the query as a parameter and have parameters that define a command that changes the query and have the back end mas…

Does it really need to be generated on the backend and passed around like that? It seems like you're doing a ton of extra work to fit it into htmx, where coming from jquery and react, it's much more natural to generate it entirely on the frontend using plain arrays and objects, then send it as a whole to the backend in one serialized json string. Of course with one final validation on the backend, possibly with a transformation into whatever query language the backend is using. But no need for round-trips to construct it like that.
Post reply on HN