Live data from Hacker News

Please just try HTMX

pleasejusttryhtmx.com

281–290 of 530 posts

Re: Please just try HTMX

#281

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.

[deleted]

Re: Please just try HTMX

#282

I’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…

The way I'm keeping up with it (or deluding myself into believing I am keeping up with it) is by maintaining rigorous testing and test standards. I have used LLMs to assist me building C firmware for some hardware projects. But the scale of that has been such that it can also be well tested. Anyway, part of the reason I was so much slower with python is I'm an expert at all the tech I used, spending literal years of my life in the docs and reading books, etc., and I've read everything the LLM wrote to double check it. I'm not so literate with go but its not very complex, and given the static nature, I just trusted the LLM more than I did with python. The react stack I am learning as I go, but the tooling is so good, and I understand the testing aspects, same issue, I trusted the LLM more and have been more productive. Anwyay, times are changing fast!

Re: Please just try HTMX

#283

Earlier 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?

Using built-in browser apis. Not sure what you’re getting at.

Re: Please just try HTMX

#284

Earlier 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?

Many libraries provide features that were unavailable in packages that are small enough for comfort. Those features and sizes vary per project, and, as admitted, sometimes there's great use for htmx. It's just not going to be for front end, local-first, SPAs. As the author, himself, said very clearly.

Re: Please just try HTMX

#285
I love HTMX. It felt like a rebirth of PJAX. Server side template rendering is simply the best.

Too 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

#286

Earlier 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.

That’s just Vite’s dev mode. I think React is way overused but your example here is a bad one. You just weren’t aware what the dev tool was doing, it has nothing to do with the experience end users will have. It isn’t even anything to do with React.

Re: Please just try HTMX

#287

Earlier 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.

I’ve used jquery which is very heavy into html fragments. It can get unwieldy compared to keeping all your rending logic in one place and applying data to it like in React. Other comments here validate the suspicion that HTMX can fall apart in large systems.

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

#288

It 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…

Not a problem with Jinja (or any server-side templating). Both the table and dropdown render from the same context variable in one template pass. One endpoint, one data fetch, two presentation formats.

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

#289
post #265
post #172

Do 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.

Check out DecisionMe.com. 100 percent wizard pattern, htmx based nav and validation.

Re: Please just try HTMX

#290
post #7

Sorry, 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…

As you should be able to tell from the other comments, this is not a library for me. If I had ever looked into it past trying to actually implement it, I would have realized that it's actually specifically for server-rendered content and using it for front-end development doesn't actually add much. The author made that very clear in the supporting documentation, I just never bothered to check.

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.

Post reply on HN