I was talking more about thick clients. Htmx and php were just examples where “it” disappears in webdev. So please don’t take them as good examples for this top

I was talking more about thick clients. Htmx and php were just examples where “it” disappears in webdev. So please don’t take them as good examples for this topic. There is a performance penalty here where every state change is a web request. That's a large part of where frontend state management libraries began That mode of operation is actually anti-frontend. Frontend (thick client) means that you have a local context with manual or eventual syncronization (aka [auto]save and [auto]update). Using these modern “state management” frameworks this way is double fault, cause you basically simulate 1.0 in 2.0 via now mostly useless approach that didn’t make much sense to begin with. Request penalty is not a new thing. 20 years ago LAN servers had connection properties similar to the modern internet. Somehow (and I say this ironically, it’s very straightforward “how”) db servers, app servers, thin and thick clients and bare apps worked without “managing state” via some semi-functional but not really DSL language wrapping anominations. Only web, which was always a second class dev env invented the problem from its own poor childhood: jquery et al, no concept of permanent storage, poor io-unaware language until around 2015.