Live data from Hacker News

Htmx 4.0

four.htmx.org

61–70 of 217 posts

Re: Htmx 4.0

#62

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…

There's definitely something to this: I expect LLMs to hurt the adoption of htmx and most smaller web libraries. That's fine: it's always been a labor of love and is BSD 0, so I hope the ideas are interesting and that the people who decide to use it enjoy it.

It may do the opposite! My sense of LLMs is that simplicity beats training.

If you have 1/5th the context to consume, that's going to generate better code than the comparable typescript, even if the language is an esoteric one.

Re: Htmx 4.0

#63

Earlier quoted context omitted.

There's definitely something to this: I expect LLMs to hurt the adoption of htmx and most smaller web libraries. That's fine: it's always been a labor of love and is BSD 0, so I hope the ideas are interesting and that the people who decide to use it enjoy it.

I think, at least for the next few years, certain preferences and consensuses were accidentally embedded in the models to your benefit. They love htmx! Claude will independently suggest using it instead of more general js frameworks for smaller projects. A gpt model told me, and I wrote this down because it was striking, "htmx won the argument it was making." It's the same thing with rust. I'm an ocaml expert and oca…

I agree with this and I'd also say - I've been vibe coding in OCaml since before the training data was good.

All the stuff I lost in training data I gained back in having great compiler feedback.

I don't think agents are nearly as restricted by language or training data as we think.

Re: Htmx 4.0

#64

Earlier quoted context omitted.

There's definitely something to this: I expect LLMs to hurt the adoption of htmx and most smaller web libraries. That's fine: it's always been a labor of love and is BSD 0, so I hope the ideas are interesting and that the people who decide to use it enjoy it.

I think, at least for the next few years, certain preferences and consensuses were accidentally embedded in the models to your benefit. They love htmx! Claude will independently suggest using it instead of more general js frameworks for smaller projects. A gpt model told me, and I wrote this down because it was striking, "htmx won the argument it was making." It's the same thing with rust. I'm an ocaml expert and oca…

We will see. Changing things around a bit (especially flipping attribute inheritance to explicit by default) may confuse a lot of models. Oh well, it's the right thing ¯\_(ツ)_/¯

Thank you for your kind words!

Re: Htmx 4.0

#65
It seems this version is also adding hx-live. Anyone used it before? How does it compare against Alpine.js?

Re: Htmx 4.0

#66
I really like htmx, and intercooler.js before it. It's been a while since I tried to convince a co-worker to use it, it might be time to try again. Either way I can't wait to try out the new version.

Full Disclosure, I am CEO of HTMX

Re: Htmx 4.0

#67

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…

There's definitely something to this: I expect LLMs to hurt the adoption of htmx and most smaller web libraries. That's fine: it's always been a labor of love and is BSD 0, so I hope the ideas are interesting and that the people who decide to use it enjoy it.

I've yet to see anyone try to finetune one of these qwen models on a specific framework, but if you guys care, qwen3.5-35B-A3B is rather fast and reliable for a lot of what I'd call "copy/paste" task and might be worth while to see if a fine tune could excel at HTMX universe tasks.

Re: Htmx 4.0

#68
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?

Re: Htmx 4.0

#69

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.

Depends how you set it up. Like any other project I guess. Funny enough, if you are able to produce maintainable code with an llm you could aswell lead a team of humans. LLMs shift your focus on project management and architectural choices.

I let the llm write components which are independent to each other. This works great and keeps everything clean. The times that llm would only generate unmaintainable code are long gone with OPUS, Fable and sol 5.6

Re: Htmx 4.0

#70
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 call it the GOSH stack (Go Sqlite Htmx) but HUGS is good too.

Or HAGS (HTMX, AlpineJS, Go, SQLite).
Post reply on HN