so you'd prefer that there was only one state management solution for every webapp? what if i don't need 99% of the features of this monolith library?

Seriously, try Svelte. See how its Stores API works. For bonus points, look at the Context API. Between Stores, Context, and what looks like plain ole JS in the component, state management is a solved problem. With all due respect, calling it a "monolith" out of hand just screams you haven't even looked at solutions and don't know what you're talking about.

SolidJS stores work the same.

In other words, this is basically a solved problem unless you live in the React ecosystem.

What state management does Htmx provide?

Htmx defers almost all logic to server side. That's the tradeoff, and it's a major shift from what we've become accustomed to in the last decade (unless you've been writing PHP or something similar).

You provide listening points to various parts of your app, and when something changes, all points listening to that key also make the corresponding call to the server for refresh. It sounds hokey, but it's very effective, very efficient, and pretty easy to wrap your head around.

Not any more than REST is. Server-side rendering doesn't have to be messy. In fact for most modern frameworks, it's become table stakes.

And how many libraries and frameworks and methodologies are there for server-side state management?

State on the server side is often a very different animal from client side. Whereas on the client, everything is either JS and/or a browser API, the server side allows for relational databases, Redis caches, and all sorts of other strategies, some based on session ids while others using whatever fits for that scenario. "It depends" but it's not just a library or framework as you'd imagine coming from frontend development.

Htmx is quite popular among folks who prioritize and enjoy server-side development. Svelte is likely more popular among folks who enjoy browser-based development. There is certainly some overlap between the two camps, but that's my take on it.

Not if you're a backend engineer. Then again from their point of view, they consider frontend state management to be a hopeless mess. Takes all kinds.

And why does a backend engineer's point of view on frontend state management matter? Why is a variety of options and strategies for different scenarios ok for the backend but not for the frontend?

The frontend has… a browser. It's a much more constrained toolbox. You are forced to use JS and whatever browser APIs made available to you.

The server side is only limited by what can run in a datacenter. Any language. Any service type. Any scaling profile.

Neither is more "correct". Both have pros and cons. As for why the backend engineer's point of view matters: if you are server-side rendering, you will have a better chance of going faster. A browser will always render HTML faster than JS that generates HTML on the fly, and the server side can always be made to generate HTML faster than a browser could. You can always simply throw more hardware on the server side to speed this up whereas you have basically no control over the performance profile of a random user's browser.

Look at Google search results. It's typically not JSON over AJAX; it's rendered HTML dropped into place. Why? Because every millisecond can be quantified into gained/lost revenue.

So why is it bad to choose a frontend state management strategy in a way that maximizes revenue?

> Neither is more "correct". Both have pros and cons.

I think frontend state management is a completely legitimate choice if it fits your use case.

Are you aware that these things still exist in apps no matter what kind of state management they use?