why would i use htmx?
whats the user case
Htmx 4.0
161–170 of 221 posts
Re: Htmx 4.0
#162I'm not very familiar with htmx but at first glance it seems similar to Angular. I thought Angular lost favor because of all the extra attributes and boilerplate. What makes htmx different?
How did you understand Angular to be similar to htmx? They are nearly polar opposites. Can achieve the same though.
Re: Htmx 4.0
#163[dead]
Re: Htmx 4.0
#164I 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
Could local-first HTMX ever become part of the standard library? So it could be used easily with a simple static web host?
Re: Htmx 4.0
#165I'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.
I recently used Alpine.js (client-side, I know), and, as a person that does backend most of the time and is not super knowledgeable in frontend, I was amazed.
I think that, combined with Htmx it can be a really powerful thing for lots of deployments (basically most things that do not need API/Json talking).
Re: Htmx 4.0
#166Earlier quoted context omitted.
> 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 lon…
> LLMs shift your focus on project management and architectural choices.
And a comfortable sense of short term productivity that make you tend to ignore the middle and long-term trade-offs.
It is unmaintainable unless you create a very modular architecture (read here: modules written by LLMs that will not get in the middle of others bc of their extra fat).
And even with a modular architecture, I am not convinced.
However I had a couple of success stories in the generative area, maybe bc I am so stupid that I do not detect the problems: SQL query/code generation and frontend Alpine.js-based for a small website.
Also good for one-off scripts.
But when it is about a project where you iterate for weeks, things get out of hand.
As a powerful search engine, exploring alternative solutions or doing code review, great. But the reason is not that it is extremely good at it. It is bc it is extremely fast at it and it is easy to recognize bogus stuff if you have been doing this for many years, so it saves you time. But still gives you inaccurate stuff.
Re: Htmx 4.0
#167Maybe 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…
There are an army of people using SPAs for problems best served by a simple and more traditional website. It has been a thing since SPAs started showing up so you have a whole generation who think that Next.js is just how you build for the web. Then HTMX is to them what the micro-ORMs were for me (and, if you've been in .Net for a couple of decades, I suspect you too).
It was so bizarre seeing people go from pure SPAs, to the concept of "hydrating" a website (ok still makes sense to a point), to coming up with server-side rendering like it's novel.
I mean sure, things like Next, Gatsby, etc can theoretically create the best of both worlds - static site for search engines and no-js users, content first, and very fast client-side rendered content afterwards. But that's a lot of extra engineering, considering a good server-side rendered website is also fetched and rendered within milliseconds.
Re: Htmx 4.0
#168I 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
The board chose well, they are good boys.
Re: Htmx 4.0
#169Congrats on the release. The next stage is probably some real world comparison between DataStar and HTMX 4.0. Or against Hotwire / Turbo.
And perhaps the long term goal is if half if not most of HTMX 4.0 could be inside HTML 5 spec.
Re: Htmx 4.0
#170Is it a good idea to code an app with infinite canvas (like Excalidraw) in Htmx?