Live data from Hacker News

Htmx 4.0

four.htmx.org

51–60 of 211 posts

Re: Htmx 4.0

#51
post #38

Congratulations on the release! I have enjoyed working with htmx very much. I'm still skeptical of htmx being the foundation for a 100-year web service, but I think this is a really worthwhile goal. I'll add that aside from static HTML, I don't have a better option.

Thinking about how well your web architecture will hold up for 100 years (or even 10 years) is bikeshedding and a pointless exercise. Perfect is the enemy of good and all that. If something is useful, it’s possible to fix the architecture later. The only counter-example I know of has been GitHub, which was built on RoR and so poorly planned that it’s still biting Microsoft on a regular basis.

Sure but it's a spectrum. Surely some choices will age much more poorly than others.

Re: Htmx 4.0

#52

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…

The main issue HTMX address is reducing complexity and LLMs doesn't solve it.

I'd expect it to be the other way around: LLMs will increase HTMX(and similar solutions) adoption because alongside of being excellent at writing HTMX there are also excellent writing web components.

React, vue and similar still have their use case, but htmx + web components can drive you really far.

Re: Htmx 4.0

#53

> `hx-alpine-compat` - smooths over compatibility issues between htmx and Alpine.js I looked into this when I tried HTMX 4 on a project earlier this year. I actually found that https://alpine-ajax.js.org/ was smaller than HTMX while providing all the features I needed. It is one of the sanctioned projects they link to so I felt good using it

great library, we link to it on our alternatives page

Carson! FYI:

"let us rething how extensions can and should work,"

I think you meant rethink here.

Re: Htmx 4.0

#55

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…

By default LLMs will start creating a tangled hard to test mess of javascript. But if you ask them to do TDD they will, and if you give them access to Playwright and have them write playwright tests this can all work.

The advantage for the LLM is the same for humans. With the right abstractions, code can be written quicker and more robustly.

To get more hands off with LLMS you really want to have a lot of engineering rigor. A big part of that is a focus on tests. If your abstractions make testing easier, your results will be a lot better. For Javascript the more you can test logic without DOM manipulation and without playwright tests, the better.

I found LLMs to be default to and be pretty good at working with HTMX, but not great (mostly lots of state synchronization issues). The focus on DOM markup of HTMX does not lend itself well to simplifying testing. I don't claim to be an expert at HTMX, but I don't see a separate section on testing in their documentation.

I am trying out the foldkit framework because it makes a lot more testable outside the DOM. Its probably too heavy weight for most humans (and for simple apps- it only seems appropriate for client-side apps), but I will see how well LLMs can work with it.

Re: Htmx 4.0

#56

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.

Re: Htmx 4.0

#57
post #38

Congratulations on the release! I have enjoyed working with htmx very much. I'm still skeptical of htmx being the foundation for a 100-year web service, but I think this is a really worthwhile goal. I'll add that aside from static HTML, I don't have a better option.

Thinking about how well your web architecture will hold up for 100 years (or even 10 years) is bikeshedding and a pointless exercise. Perfect is the enemy of good and all that. If something is useful, it’s possible to fix the architecture later. The only counter-example I know of has been GitHub, which was built on RoR and so poorly planned that it’s still biting Microsoft on a regular basis.

100 years, sure, but 10 years? Definitely not bike shedding, I'd hope your website can stay up for 10 years at least.

Re: Htmx 4.0

#58

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…

By default LLMs will start creating a tangled hard to test mess of javascript. But if you ask them to do TDD they will, and if you give them access to Playwright and have them write playwright tests this can all work. The advantage for the LLM is the same for humans. With the right abstractions, code can be written quicker and more robustly. To get more hands off with LLMS you really want to have a lot of engineering…

[deleted]

Re: Htmx 4.0

#59
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 also like the same stack, as it plays very well with a terminal focus workflow.
Post reply on HN