> HTMX’s docs seem to hand wave away front-end state management as something that no longer applies.

I feel like you're begging the question that you need front-end client & state. I have ASP.NET apps still running from 10 years ago. They're fine. I'm adding HTMX to remove the page reloads. Why do I _need_ anything else?

(edited HTML => HTMX)

I've been consulting for a large org where someone decided that every web app needs to use a consistent pattern, and they mandated Angular. This could have been React, Vue, whatever, the point is that they picked a client-side JavaScript framework for all of their web apps.

Turns out that they weren't actually making web "apps". They were making web sites with mostly read-only content and a handful of web forms.

Traditional server-side templating, like Razor pages, is a well-established method for handling this. Something like HTMX adds the tiny bit of client-side interactivity that is actually required. Nothing else is needed.

The article talks about about reducing code size to 2/3rds and you just handwave that away!?

That's the exact same thing I've been telling my customer! They're literally bloating out their codebase three times over (3x!) by using JavaScript client-side rendering instead of plain, ordinary, boring, and simple server-side rendering like they should have.

For every single thing that they do, they need a C# bit of code and a TypeScript bit of code, and a whole API thing to wire the two up. They are forced to use distributed monitoring spread across the browser (untrusted!) and the server! Deployments have to factor in client-side cache expiry! And on, and on, and on.

I did a demo for them recently where I rewrote several thousand lines of code with 50. Not fifty thousand. Fifty.

"Thousands of lines? This is fine" -- says the developer on the hourly contractor rate.

The more developers you have, the less React SPAs are scaling in my own experience. In my current company it's even visible on the bundling graph itself over time.

https://htmx.org/essays/a-real-world-react-to-htmx-port/

(Of course, it depends: https://htmx.org/essays/when-to-use-hypermedia/ but, if we are going to speak in generalizations…)

Does client-side state often need to exist independently of server-side state? I’m having trouble imagining a shopping cart or email draft being optimal UX-wise without the ability to resume on a different device.

For things like dropdowns and modals, you can bring in _hyperscript, Bootstrap, Alpine, or even CSS hacks (my preferred approach).

> the rich and bountiful lands of JSX and TypeScript

One person’s richness is another person’s needless complexity.

JSX is cool when you first try it, but the novelty wears off (at least for me it did). There are superior templating languages (Django, Jinja, EEx, erb) that don’t require bizarre syntax such as nested ternaries, and they make it feel like you’re just using a slightly-enhanced superset of HTML (not to mention being able to use them to render things other than HTML).

As for TypeScript, with the checks stripped out at runtime, you’ll still need to validate and test the assumptions your typed code is making. Frankly, TS seems like busywork to me.

Finally, Progressive Enhancement is a thing with htmx. You might be able to have it with React, but then you introduce even more complexity into the build system.

For shared reference, here are the latest Django docs:

https://docs.djangoproject.com/en/5.0/

And Django 5.x docs on DevDocs, which mirrors documentation for many projects with a unified interface:

https://devdocs.io/django~5.0/