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

161–170 of 216 posts

Re: Why Gumroad Didn't Choose Htmx

#161

Post by nsonha »

mardifoufs wrote: post #68
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.

And a lot of people are happy with react. Not sure what your point is. I mean of course people using a more niche framework will usually be more happy about it, because early adopters usually choose to use the technology. Like, it's rare to come across htmx (or svelte, or solid) in a corporate job for now, which means that almost all of their users like said frameworks enough to use and talk about them in their free…

Hey I like React to, I'm actually complaining that often React is used as a scapegoat and and it would be a weak/not really on point criticism for htmlx. I mean people should understand that htmlx is bad because it's clunky, not because it's unpopular and there is no job.

Re: Why Gumroad Didn't Choose Htmx

#162

Post by necovek »

cheema33 wrote: post #103
SrslyJosh wrote: post #91

Earlier quoted context omitted.

If your devs can't work without something writing their code for them, why are you hiring them?

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

This is very much like saying "good engineer using StackOverflow will run circles around a good engineer who isn't".

AI does help an engineer who embarks on a new voyage through unfamiliar APIs to guide them with usage patterns, but some people become much more efficient by going through the library docs.

Typing out the code is the smallest part of a "good engineer's" job (and even so, having to adapt most of AI generated code is slower than typing it out yourself once you do understand the APIs).

I do think it might work well for MVP-style quick prototyping, but using this as an applicant qualification criteria seems so weird (even when building an MVP, you want some tension between building it quickly and building it the right way).

Re: Why Gumroad Didn't Choose Htmx

#163

Post by mardifoufs »

nsonha wrote: post #161
mardifoufs wrote: post #68

Earlier quoted context omitted.

And a lot of people are happy with react. Not sure what your point is. I mean of course people using a more niche framework will usually be more happy about it, because early adopters usually choose to use the technology. Like, it's rare to come across htmx (or svelte, or solid) in a corporate job for now, which means that almost all of their users like said frameworks enough to use and talk about them in their free…

Hey I like React to, I'm actually complaining that often React is used as a scapegoat and and it would be a weak/not really on point criticism for htmlx. I mean people should understand that htmlx is bad because it's clunky, not because it's unpopular and there is no job.

I completely misunderstood your original comment then, sorry!

Re: Why Gumroad Didn't Choose Htmx

#164

Post by bitbasher »

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…

> LLMs will further amplify the existing winner-take-all, first-mover nature of dev tools

Or, taken another way-- developers not using LLMs will be more likely to be first-mover winners.

Re: Why Gumroad Didn't Choose Htmx

#165

Post by recursivedoubts »

chrisco255 wrote: post #156
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.

What do you mean by timers and intervals?

Re: Why Gumroad Didn't Choose Htmx

#166

Post by syndicatedjelly »

chrisco255 wrote: post #156
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.

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.

Re: Why Gumroad Didn't Choose Htmx

#167

Post by syndicatedjelly »

chrisco255 wrote: post #157
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.

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.

Re: Why Gumroad Didn't Choose Htmx

#168

Post by Ayesh »

bumbledraven wrote: post #4

Kudos to htmx.org for hosting this essay.

Yeah, I expected a bit of a rant or sarcastic post, but I'm genuinely happy it's a good post with good points. I use htmx in a couple of my projects and it's been great! Posts like these give me more confident about using htmx because they seldom show where they excel and where they fall short.

Re: Why Gumroad Didn't Choose Htmx

#169

Post by mvkel »

markmark wrote: post #126
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 adva…

Exactly this. The language with the biggest community wins, even if it may be technically inferior

Re: Why Gumroad Didn't Choose Htmx

#170

Post by edanm »

alexpetros wrote: post #77
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…

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