Hey, I created htmx and while I appreciate the publicity, I’m not a huge fan of these types of hyperbolic articles. There are lots of different ways to build web apps with their own strengths and weaknesses. I try to assess htmx’s strengths and weaknesses here: https://htmx.org/essays/when-to-use-hypermedia/ Also, please try unpoly: https://unpoly.com/ It’s another excellent hypermedia oriented library Edit: the arti…
fwiw I'm the CEO of htmx, and I am a huge fan of these types of hyperbolic articles.
Please just try HTMX
281–290 of 530 posts
Re: Please just try HTMX
#282I’ve been a fan of this philosophy since the Intercooler.js days. In fact, our legacy customer portal at bomquote.com still runs on Intercooler. I spent the last year building a new version using the "modern" version of that stack: Flask, HTMX, Alpine, and Tailwind. However, I’ve recently made the difficult decision to rewrite the frontend in React (specifically React/TS, TanStack Query, Orval, and Shadcn). In a perf…
This got me thinking: I am not about to fight windmills and the future will unfold as it will, but I think the idea of "LLM as a compiler of ideas to high-level languages" can turn out to be quite dangerous. It is one thing to rely on and not to be able to understand the assembly output of a deterministic compiler of a C++ program. It is quite another to rely on but not fully understand (whether due to lazyness or co…
Re: Please just try HTMX
#283Earlier quoted context omitted.
Plain react is arguably just as simple if not simpler than jquery. And I’m not saying every site needs to be an SPA. I’m saying if I can write everything from a simple site to an SPA in a single framework then why not use that for everything?
How do you handle routing with plain React?
Re: Please just try HTMX
#284Earlier quoted context omitted.
> You can add custom commands with invokes and custom JS, but at that point you're basically re-implementing HTMX yourself[...] Exactly. So why use a library? If it's that simple, the suggestion is akin to using a library for a toggle, when a checkbox would do. Yes, there are reasons to do it, but no, it's not what I'm going to do most of the time. ETA: sorry; I should have mentioned, I'm ignoring server stuff becaus…
Why use any library, ever? Why not just reimplement the wheel yourself every time then?
Re: Please just try HTMX
#285Too bad that the world insists on going nuts with JS everything.
Oh as a plus, AI agents are a lot more productive when dealing with server side logic.
Re: Please just try HTMX
#286Earlier quoted context omitted.
Hello world in react is just a few lines of code that mounts a react component to a dom element. There should be zero network requests beyond the initial download of html and js. You’re either doing something wrong or not actually doing a hello world.
I don’t know but vite was involved, looks like it was setting up live updates. This is part of the problem, you can’t just include a script apparently.
Re: Please just try HTMX
#287Earlier quoted context omitted.
Returning HTML sounds like a styling nightmare, if anyone changes the structure, unintended consequences. Plus it’s difficult to reason possible states of the UI with fragments sitting on the server, possibly dynamically built on the server. Very jquery/PHP ish. I had my fun and don’t want to go back.
Clearly you haven't used something like HTMX. Do you understand what "returning HTML by the server" mean? You are basically sending back a view, like you would in any other framework actually. This would be the exact same pattern as displaying or dynamically adding a new component from either React or Vue. It doesn't create any styling issue at all, nor any unintended consequences.
Unless you’re saying the components returned by HTMX are using the shadow dom for isolation, you can very easily run into styling problems by changing a style and not realizing some injected fragment of HTML somewhere relies on it being a certain way. I hope you’re using a monorepo because unlike typescript APIs, those HTML fragments and CSS styles are not type checked.
Re: Please just try HTMX
#288It feels like the worst of both worlds, what am I missing? I get server-side rendering. I can boot my server, and everything is there. If my model changes, I can update the view. It's cohesive. I get client-side rendering. The backend returns data, the frontend decides what to do with it. It's a clear separation. The data is just data, my mobile app can consume the same "user" endpoint. This seems like a worst-of-bot…
The "two endpoints" concern assumes you're fetching fragments independently. If you're composing a full page server-side, the data is already there
Re: Please just try HTMX
#289Do not use HTMX for anything other than very simple CRUD apps. The vast majority of the time you'll be wishing you had client side two way data binding and state management. If you want "simple and not React", just use Alpine.js. It has way better ergonomics and features than HTMX and can do essentially everything HTMX can do.
This matches my experience. State management is the key thing - you end up needing to put way more on the backend then you'd otherwise like to. Quick example: something like a multi-step "wizard" is far more difficult to express in HTMX than with any SPA-ish pattern.
Re: Please just try HTMX
#290Sorry, but it's a no from me. htmx is a great idea, but it's not necessary anymore. We're very close to invokers being baseline (and even that is just an extension of the "composedPath includes -> invoke" pattern), and that will take care of plenty of what htmx was designed to do. Between features like that, and web components, I'm very happy to stick with "plain HTML" (no frameworks; my web components do not draw fr…
Invokers don't give you what htmx gives you out of the box. If you want to, for example, have an invoker command to fetch a resource and swap it in to the page, you have to write custom JS for that. That's the thing that htmx gives you out of the box, along with error handling, progress indicator support, history support, animated transitions, and a host of other features. If you don't need or want all these and are…
So I relayed my personal experience with it and then, because of this great comment section, I became aware that I was trying to use it for things that it isn't helpful for. Because, yes, I would have to write custom JS for the functions I would try to invoke with invokers, but I would also have to write custom JS for the functions I would try to invoke with htmx. There's no change, for me, other than including 14kb that I do not need to run a PWA.
So you can take whatever issue you want with my impatience and my myopia in disregarding it as not useful, but my complaints are not immaterial. It doesn't do what I said it doesn't do, and you seem pretty happy to confirm that. I shouldn't have expected a cat to bark, and I regret it. Hell, I'd apologize if someone felt mislead, or if someone feels I'm misleading people in my aspersions. But - like any app - my apps swap out html all of the time and there's nothing that htmx provides that helps me with that in a way that's worth the weight.