[JodieBenitez]

> The main problem is that the state of your frontend application is in the URL.

There are plenty of ways to maintain state, including server store, sessions, localstorage, cookies, etc. Say you want the user to be able to customize the app layout: that doesn't need to be in the URL. Now say you provide a search functionality where the user can share the results: now your search criterias definitely should be in the URL.

It's not a black or white, one actually has to think about what the application must achieve.

> modern UI where you might have many different zones, widgets, popups, etc.

This is completely independent from the HTMX matter, but not all your application functionality has to fit one screen / one URL. There's a thin line between "modern" and bloat. Unfortunately this line is crossed every day.

> React / Vue that all provide their version of a state store that can hold the state

And many times they duplicate what's already available server-side.

[fvdessen]

> There are plenty of ways to maintain state, including server store, sessions, localstorage, cookies, etc. Say you want the user to be able to customize the app layout: that doesn't need to be in the URL. Now say you provide a search functionality where the user can share the results: now your search criterias definitely should be in the URL.

> It's not a black or white, one actually has to think about what the application must achieve.

You are explaining quite well why it's hard to manage the state in a htmx app. As your app grows up all this mumbo jumbo of url, session cookies, cookies, database models becomes tangled spaghetti. You don't have to do any of this in a Vue / React app, and that reduction of complexity alone is worth the weight of those frameworks.

[JodieBenitez]

> You don't have to do any of this in a Vue / React app, and that reduction of complexity alone is worth the weight of those frameworks.

Well... I don't know what to say. What you call complexity is what I consider web development 101 really. And it is well worth the price: Better user experience, better performance, less code, better adherence to standards, easier app maintenance and more.

But what did I expect ? These days web developers resort to gigantic dependencies list for the most basic things.

[jon-wood]

> You don't have to do any of this in a Vue / React app

Something has to do this in an app regardless of what UI framework you're using. Deciding where a particular piece of state lives is fundamental to web development, and yes, URL/session/cookie/database are all valid options depending what kind of state you're storing.

[kmacdough]

User state is sometimes necessary, but frequently a crutch to avoid answering the real questions. Much of the time, this user-state is at the core of many performance and behavior issues as the user is burdened with unnecessary DOM reorganization. If the layout is dependent on more than just URL parameters and simple server state/cookies, then it begs the question: does this page really have a specific, well-defined purpose? If not, it's ripe for noisy UX, confused users and hard to untangle interface bugs. If so, you probably shouldn't be doing so much on-the-fly DOM configuration. You're not building an OS or window manager here.

Notably, none of this is incompatible with React/Vue where you need it.