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
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)
Yeah, typically I end up building websites (for myself and others) in basically three "lanes". Static HTML/CSS files, great for docs, presentations, reports and similar. Or, websites with some interactive/dynamic elements, HTMX is great for this. Or, fully fledged "client-side apps" where it's more of an application than website, then I go full out dynamic programming with ClojureScript and similar approaches.
I'm not sure why so many people seemingly fall into the trap of trying to find one tool and then use that absolutely everywhere. I mean, I'm familiar with it as in "it's fun" as I used Nix as a framework for a static website builder, but I keep seeing people making those sort of choices professionally too. Like when React first became popular, then suddenly people try to jam it into absolutely everything, until they slowly walk back and then after some years agree that maybe it's good for some things, not for everything and not as a default.
Ha, that was me and Hugo, back in the day, for static sites.
And, yeah, HTMX is truly great for sites with limited interactivity. You really, really do not want or need a full React Leaning Tower of Pisa stack for a simple presentational website.
> 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)
My concern with is that i build line of business applications for a living, and literally, every project i work on ends up growing in scope such that even the simplest ones, reach a point where the customer asks for items that are just much simpler to do with a front-end framework. And these are often cross cutting concerns, such that it is not as easy as simply adding some js to one page.
Example: "i want to be able to reorder all the columns of all the tables of the website, and hide some columns, with my preferences remembered for each table". Customers pull that kind of thing off their hat every time, such that even "basic websites" can move out of the trivial territory any time. And this is just the most trivial example i can think of.
I want the tech stacks i use to be future proof, as in not having to rewrite everything when requirements become more complex (as it is also typically a time where we aren't given much time budget, as they need it for yesterday).
For something for which i fully control the roadmap, i may consider htmx (but even then, even my own products grow in ambition rapidly) however for customer projects i find this choice way too risky.
I need to be able to capitalize on the tech infrastructure i've built as requirements get complex, both due to customer time constraints and because this is where we get some of the highest profit margin from our work. Having to rework most of what i've done every time a complex requirement comes up, would be inefficient with this regard.
To me it's a case of knowing your tools in depth, to make meet most requirements (including from a performance perspective). Maybe erlang or go would have been more suited for a project from a philosophical perspective but since i specialize in .NET + angular, unless there is hard blocker, i'll use this tech stack, and everything is fine from the perspective of the customer. But i gain that the project is future proof and i won't need to reengineer it when it moves of its initial sweetpot.
From the same author: https://grugbrain.dev/#grug-on-saying-no
Thanks for sharing, I agree with what he says.
I've reached a point in my career where i can essentially call the shots as far as engineering and even product direction is concerned.
But recently had to do some consulting as an IC due to circumstances (worst case scenario deal closing delay), and i can tell you that there are places where non-technical people make tech decisions without consulting anyone. Also in my already quite distant qconsultant past (wow, time flies) while it has always been common for me to sort out requirements, and help with business analysis to align them with engineering, even when you dismiss flying unicorns, the class of core requirement evolutions that can make you regret choosing a tech stack is still very large. I've seen a couple of folks fired literally due to this.
Even now that i call the shots and sell products rather than time, the roadmap uncertainty is still high (largely driven by the need to make products user-friendly enough based on feedback), so i default to .NET + angular as it keeps my game open.
B2B2C at the cross-roads of ecommerce, fintech, blockchains. So you need to deal with vendor integration requirements while making the integration user-friendly from a UX perspective + and keeping your own core UX premium, especially for the B2C segment, and being competitive. Requirements change fast, especially at the beginning, so you don't want your engineering to constrain you or make things more difficult than necessary.
Nice. Curious about your views on SolidJS?
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).
> ... 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.
> 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.
I don't understand (possibly because I lack Angular experience): what is it about a .NET backend using HTMX that requires presentation concerns to be mixed with business logic?
Don't you have to maintain that separation either way? Your core/application logic shouldn't know how its result is ultimately represented. That could be JSON or HTML over HTTP, Protobuf over a TCP stream, or a custom binary protocol over a Unix socket.
Obviously those representations matter at the presentation/transport boundary, but why should choosing HTML force that concern into the business logic?
> mixing presentation concerns with business-logic
That's on you not on your platform
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.
Datastar relies way to much on IDs everywhere that it's not ergonomic and turns into a chore. It's also a bit too complicated for its own good trying to solve everything.