Hacker News new | ask | show | jobs
by spinningslate 1037 days ago
That's not my experience based on two scenarios:

1. Server-side rendered sites in Python using either Django or FastAPI/Jinja2 and htmx;

2. Dotnet back end with Angular front end.

In practice - for the apps I've been involved with - option (1) provides a more than acceptable user experience. There's no doubt Angular can go beyond the capabilities of SSR+htmx. But, in practice, it's in the long tail. Throw in the odd js lib, e.g. for charting, and option (1) is good enough for the vast majority of things.

The complexity is not comparable: (1) is much simpler. For a start, all logic is in one language. There's no separate build for the front end and back end; no need to reconcile state in a front end cache with the back end. There's no need to export every view as a REST API; it's a native function that gets called from the view handling function.

Others will have different experience: I'm not saying this is universal. But in my experience, objectively, it's not true that the complexity moves from js to htmx. At least, not if that implies the complexity is equivalent. It's just not the case.

1 comments

Not sure you've solved the complexity when you've just slotted in another front to a general solution that is over-engineered. You could have replaced either scenarios with a single NextJS or SvelteKit solution. Go above and beyond in "complexity", write your Node backend (keeping it one language, JavaScript), and use vanilla HTML and JS to consume that.

To me, htmx isn't as revolutionary as people make it out to be, and possibly that's due to the fact I'm just not burdened by the old days of gigantic Angular apps and massive ASP.Net stacks. My history was mostly JQuery where needed (which was all the time before JS got its act together).

> My history was mostly JQuery where needed (which was all the time before JS got its act together).

htmx should remind you of those times.

I certainly has for me - it's just (fundamentally) a fancy and clever wrapper around jQuery ajax requests made via HTML attributes.

> You could have replaced either scenarios with a single NextJS or SvelteKit solution.

But then I would be using only JS. I want a backend to be something else so that I don't go insane.