Live data from Hacker News

Htmx 4.0

four.htmx.org

141–150 of 213 posts

Re: Htmx 4.0

#141
post #109

Maybe a contrarian view, but as someone very knowledgeable about .NET API backends + angular on the frontend, I've found that HTMX made things more difficult as it required me to move back to mixing presentation concerns with business-logic and data concerns (basically have the backend produce the UI, which is whole point of HTMX). This is not a criticism but I suspect that the people enjoying HTMX are either people…

> mixing presentation concerns with business-logic

That's on you not on your platform

Re: Htmx 4.0

#142
post #140
post #7

Congrats and thanks! htmx brings me joy. Pretty much every experiment I build now starts with Go, htmx, and SQLite to keep things simple and fast but still responsive. I put a few more thoughts about this here: https://housecat.com/blog/the-hugs-stack-hypermedia-unix-go-...

i use this stack quite a bit too. i made the claude do some load bearing 360 backflips, gate and seam a whole buncha smoking guns, and bolt go-starlark on top of this so i can just declare little web apps like its streamlit but it doesn't feel sucky like streamlit. i get to just write little blurbs of python-looking code and i get these fully reactive tools. probably my favorite and most used abstraction that came fr…

Go backend with Starlark for dynamic behavior is a great combination. I have been building https://github.com/openrundev/openrun with that approach, mainly for teams to deploy internal tools. It can be used to deploy any containerized application. The management UI for OpenRun is built with the Hypermedia approach https://utils.demo.clace.io/console/

Re: Htmx 4.0

#143

I've always been a fan and supporter of HTMX, but lately I've wondered how beneficial it is now that LLMs can generate JavaScript for us. HTMX was especially useful when I wrote JavaScript by hand because I appreciated its higher level of abstraction and simplicity. I also struggled to make it work with AlpineJS and eventually had to resort to plain JavaScript, which gave me finer control. Normally, switching to Java…

Out of curiosity, are you defaulting to vanilla js in your agentic dev stack? Or do you have the llm use a framework like react?

I've only tried vanilla JS so far

Re: Htmx 4.0

#144

I've always been a fan and supporter of HTMX, but lately I've wondered how beneficial it is now that LLMs can generate JavaScript for us. HTMX was especially useful when I wrote JavaScript by hand because I appreciated its higher level of abstraction and simplicity. I also struggled to make it work with AlpineJS and eventually had to resort to plain JavaScript, which gave me finer control. Normally, switching to Java…

> now that LLMs can generate JavaScript for us. You mean generate unmaintainable JavaScript for us.

Not my experience. I have large production apps that I'm able to maintain just fine with thousands of lines of JS.

Re: Htmx 4.0

#145
post #39

Earlier quoted context omitted.

All apps I build are server-side rendered. I'm not sure how your comment changes the the question I'm asking.

apologies, i thought you were saying you were switching to SPAs because LLMs understand it better. I see some version of that comment nearly daily now. Carry on!

Ah no worries. No SPAs for me, SSR all day.

Re: Htmx 4.0

#146
post #20

Before vibe coding was a thing, HTMX made it super easy for me to implement Ajax like features. It was the most approachable library I've ever seen, and I'll always be grateful for it.

What about vibe coding makes HTMX something that you speak about in the past tense? Are you just generating frontends in vanilla JS now?

It's day job tasks/database CRUD, so I tell the LLM what I need. I used to write all my work apps in plain jane PHP/MySQL and I use that as a guide for the LLM, as in use this app as a guide on how I want things. The bonus of using plain PHP/MySQL/PDO is that the apps are small, so no issues with context windows or using complex frameworks.

Re: Htmx 4.0

#147
post #73

Earlier quoted context omitted.

Given the number of people claiming to be CEO of HTMX, I have to ask: what’s the joke I’m missing?

There is something here, but I am not sure if it's the whole story: https://htmx.org/essays/lore/

This is a social media presence worth striving for.

> You can put it on your LinkedIn, because it’s true.

I only take LinkedIn seriously under extreme protest, so this is extremely tempting.

Re: Htmx 4.0

#149
post #109

Maybe a contrarian view, but as someone very knowledgeable about .NET API backends + angular on the frontend, I've found that HTMX made things more difficult as it required me to move back to mixing presentation concerns with business-logic and data concerns (basically have the backend produce the UI, which is whole point of HTMX). This is not a criticism but I suspect that the people enjoying HTMX are either people…

I'll shill datastar for a second, there's barely a notion of frontend state management if you treat HTML as a projection surface with interactivity. I'd argue HTML is the most efficient wire format for interactive web apps, especially with streaming + compression. Seriously DB->json->client->toHtml DB->toHtml->client Just imagine if that html wire format also conveyed the interactivity too and you eliminate the issue…

Datastar relies way to much on IDs everywhere that it's not ergonomic and turns into a chore. It's also a bit too complicated for its own good trying to solve everything.

Re: Htmx 4.0

#150
post #101

Earlier quoted context omitted.

Thinking about whether a web architecture will hold up for 100 years is bikeshedding, is bikeshedding as well

Only if you don’t know what bikeshedding is and want to broaden the definition so much that it’s meaningless. This is Hacker News. This is exactly the place to tell people they’re overanalyzing and should just build something.

Sir, this is a Wendy's
Post reply on HN