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

181–190 of 216 posts

Re: Why Gumroad Didn't Choose Htmx

#181

Post by riffraff »

freeone3000 wrote: post #59
riffraff wrote: post #39

Earlier quoted context omitted.

I don't think convention over configuration causes LLMs any problems, GitHub copilot generates code matching rails conventions quite easily for example.

Because there’s enough rails code in the training data to determine the proper conventions :) if you’re making something new without this glut of data, it’s going to be much more difficult for a coding assistant to match a convention it’s never seem before.

true, but the conventions it has seen are the same across all similar domains not just same framework/language, copilot "picks up" the similarity.

What I mean is: if you name your modules consistently, say Operation::Object::Verb or Action::ObjectVerb or ObjectManager.doSomething it's really easy for the LLM to guess the next one, just as it is easy for a human.

Add a new file actions/users/update.rb and start typing "Act" and it may guess "class Actions::Users::Update, and start to fill in the code based on nearby modules, switch to the corresponding unit test and it'll fill it in too.

Source: we have our own in-house conventions and it seems copilot gets them right most of the time, ymmv.

Re: Why Gumroad Didn't Choose Htmx

#182

Post by anonzzzies »

steve_adams_86 wrote: post #180
anonzzzies wrote: post #178

Earlier quoted context omitted.

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…

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

Re: Why Gumroad Didn't Choose Htmx

#183

Post by wodenokoto »

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…

I saw a tool that had a page dedicated to AI to read. Basically you would point your llm to that page as the initial prompt and from there could start asking questions. I thought it was an interesting idea, but apparently not interesting enough to remember who did it or even check how that page looked.

Re: Why Gumroad Didn't Choose Htmx

#184

Post by sgarland »

edanm wrote: post #170
alexpetros wrote: post #77

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?

ffmpeg, for one.

Re: Why Gumroad Didn't Choose Htmx

#186

Post by crubier »

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

What would look natural for this use case? Can you write the code?

Re: Why Gumroad Didn't Choose Htmx

#187

Post by PaulHoule »

WickyNilliams wrote: post #176
PaulHoule wrote: post #98

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

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 mash that into the query.

The user interface for nested queries would be more complex than for the flat queries (which can usually be updated incrementally, adding or removing just one tag) but could probably be redrawn from the back end whenever it changes.

Re: Why Gumroad Didn't Choose Htmx

#188

Post by majewsky »

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.

> In my experience, a good engineer using AI tools will run circles around a good engineer not using AI tools.

Even supposing that is true, what if you have a choice between a bad engineer who uses AI and a good engineer that won't?

Re: Why Gumroad Didn't Choose Htmx

#189

Post by righthand »

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.

> and it’s intentionally misleading design to get you to host there.

Re: Why Gumroad Didn't Choose Htmx

#190

Post by q0uaur »

wodenokoto wrote: post #183
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…

I saw a tool that had a page dedicated to AI to read. Basically you would point your llm to that page as the initial prompt and from there could start asking questions. I thought it was an interesting idea, but apparently not interesting enough to remember who did it or even check how that page looked.

its actually a big thing i am waiting for - both websites and ai tools to agree on a way to facilitate this.

i'm doing some game development in godot as a hobby, and the current llm's are really bad at it - very often i get code suggestions that use ancient versions of gdscript or the engine. I'd love to have a big enough context window and the tooling needed to go like "look at these godot docs for the current version: (insert link)" and then ask my questions, i think it would fix 99% of these issues. same with other less well-known tools and languages.

Post reply on HN