The problem causing burnout isn’t the framework but all the tooling around it. Webpack alone has probably caused as much PTSD as a minor war and if you’re not in frontend you don’t know to just install Vite, copy a tailwind config, and get started. With HTMX you just add a script tag and go. The developer experience for adding some simple dynamic features is leagues better, even if the DSL is esoteric.
Coming from a C++ background I will happily write webpack configs for the rest of my life…
In the backend you choose and control one runtime so the framework can integrate tightly with the authoring workflow.
Concretely, Rails, Django, Spring, Elm, all have great tooling and are much easier to work with than frontend stacks.
Now if you know what you're doing it's much better now that everyone has converged on ES6 modules and with the latest generation of build tools like Vite, all you need to do is npm install some packages to provide zero-config support for frameworks like React, Svelte, etc. But it used to be so much worse.
As for HTMX, I've been playing with that on an evening / weekend project and absolutely love it. Getting it working with Django was maybe very slightly harder than with other backend frameworks as Django doesn't have great support for template fragments. Once I'd sorted that though, I had a decent interactive UI on top of my app very quickly, all while being completely new to HTMX. I can imagine being incredibly productive with it with a bit more learning / use.
But if this isn't something you do full time and just occasionally tinker with for a personal blog or something, the ecosystem's signal-to-noise ratio can be very, very low, and it's hard to know the right way to get started, and what's important to worry about or not, or how to resolve obscure errors from some tiny part of the buildchain.
3-4 years ago, it was especially bad, when you had to bundle together a bunch of different things yourself (webpack, eslint, typescript compilers, react, state managers, routers, etc.) all from scratch, and any one of those could cause serious incompatibilities with the other parts. These days it's a lot better with things like Next (for bigger projects) or Vite/Astro for simple sites, since they abstract away all the tooling setup for you (and 1-click deploy on Vercel helps a lot too). But if you're not deep in the frontend world, the differences between all these random projects can be pretty non-obvious. Plus, JS changes so quickly it's impossible to keep up with the bleeding edge... maybe, hopefully, it'll slow down now since all the VCs are shifting to AI instead?
And that's just the frontend side. If you need a backend too (as opposed to simple API routes or a headless CMS or something), then you have to deal with all the differences between Node.js vs browser JS, polyfills, different Node versions, serverside vs clientside rendering... it's a lot of mental overhead vs the traditional "business logic lives on the backend, the frontend just handles presentation" model. HTMX seems like a good tool for a heavy backend and a light frontend, which probably isn't the kind of project that most full-time frontend devs would work on anyway.
At the end of the day, I think it's cool the Web has still managed to maintain its (relative) openness and tool-independence. You can still make a functional site in anything from an expensive IDE + huge framework to Notepad, and everything in between, and there's never really just "one right answer"... totally depends on your project's needs, your team's skills & resources, and various tradeoffs. I'm not the target audience for HTMX either (the React ecosystem is just far too useful, with NPM and MUI especially), but it's cool that it exists.
.NET Framework has it's flaws, but the ease of development of ASP.NET WebForms or MVC sites is awesome.
The JS ecosystem, not only is it confusing, all too often documentation, forum posts, etc. out of date making the barrier to entry that much higher.
I heard they've changed a lot since then, but it's still not super popular (at least in the US). As a web dev, it's a stack I'd be reluctant to invest in because I've never seen a company I'd want to work for who uses it... when even Microsoft themselves jumped ship to JS for so much web work (like VScode or Teams being built in webviews), it's hard to take their other web stack seriously. That said, I'd absolutely consider .NET for a desktop app!
--------------------------
> The JS ecosystem, not only is it confusing, all too often documentation, forum posts, etc. out of date making the barrier to entry that much higher.
Lol, absolutely :( Even within the same codebase, like the one I was working on yesterday, there can be like 3-4 major generations of JS paradigms across different files. It's only a few years old, but feels like it was decades and worlds apart...
I really hate that instability in the JS ecosystem. I guess that's the opposite problem of Microsoft... instead of stable but closed single-vendor support, we have unstable open innovation across 50 different frameworks and ten thousand packages with a million versions. It can be a nightmare to work in for sure.