2 ms·

> Can you recommend a blog post about “state management” in non-frontend? E.g. some server or maybe a desktop app like e.g. your backup manager. Because my whol

by Izkata 2y ago

> Can you recommend a blog post about “state management” in non-frontend? E.g. some server or maybe a desktop app like e.g. your backup manager. Because my whole premise is that the “problem” is self-imposed, which react is literally the part of. It's largely unnecessary there because those can talk directly to the database and use it as their data store without a large performance penalty. Plenty of server-based systems like PHP don't even have persistent state to manage, whatever wasn't stored in the database is discarded when the response is sent. > It is a collective delusion which suddenly disappears when people get forced out if it, by e.g. going htmx route. 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, with Backbone providing objects that would be synced with database tables and acted like a local cache.

wruza 2y ago
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.

by Izkata 2y ago

wruza 2y ago

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.