logoalt Hacker News

rednbyesterday at 9:54 PM6 repliesview on HN

Maybe 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 preferring old-school server-side rendering or react users.

Just sharing my experience, because HTMX is the absolute darling of hacker news.

Since i mainly develop real SPA, i found that is more complex than just using typscrpit if you build something non-trivial as managing state on the server is not fun at all.

In my opinion if you are happy using angular, you'll find that HTMX is a step backward in terms for dev experience. Can't speak about react, but since it is not a battery included stack unlike Angular, i can understand why many people find they'd be better off moving things server-side instead of messing around with 15 third-party libraries. My 2 cents


Replies

perardiyesterday at 10:38 PM

I agree. We are moving away from HTMX at work, to React. (After we moved away from Angular. That was…a choice…that I didn’t make.)

Here’s the thing: there’s still a place for HTMX. Lots of places. But “building an SPA but not actually and SPA” is not a lane for HTMX. Nor do they promote HTMX for that purpose. Really quite the opposite.

Different tools for different jobs. (Me? I honestly love React, just a more minimal stack. Zustand and TanStack and Vite. No Redux or Next.JS)

show 2 replies
radicalbyteyesterday at 10:42 PM

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

aidenn0today at 12:02 AM

> ... managing state on the server is not fun at all.

Do you not have a database for your backend? Managing state is kind of their thing.

xp84yesterday at 10:58 PM

> managing state on the server is not fun at all.

Really? I've never found that difficult. Sessions exist, URL parameters exist... Perhaps in a complex SPA you can have trouble, but so many of the "applications" I've worked on are just glorified documents.

intrasighttoday at 2:48 AM

> mixing presentation concerns with business-logic

That's on you not on your platform

fatplexeryesterday at 11:32 PM

I'll shill datastar for a second, there's barely a notion of frontend state management if you treat HTML as a projection surface with interactivity. I'd argue HTML is the most efficient wire format for interactive web apps, especially with streaming + compression.

Seriously DB->json->client->toHtml

DB->toHtml->client

Just imagine if that html wire format also conveyed the interactivity too and you eliminate the issues. And you can always seperate whatever concerns you want in whatever tpl lang of your choice.

Also htmx 4 is kinda just an worse datastar funnily enough In it's own way.