In backend, most state is nicely stored in a database, in frontend, if you don’t have good foundations for component state state vs app state vs server state,

In backend, most state is nicely stored in a database, in frontend, if you don’t have good foundations for component state state vs app state vs server state, then a lot of things become complicated for a decently sized app. If you mix everything in one then you have a crazy ball of goo that’s rendering the whole UI tree everytime something small happens. Sure vdom is fast but you’ll still feel it for large apps because generating that vdom may call expensive functions over and over. Svelte is nice but I haven’t used it for a large project. I do swear by having a good separation of those states. It has served me well for over a decade building UIs in different frameworks. When component state changes, only that component changes. E.g whether a dropdown is opened. When appState, changes the whole app tree is vdom diff rendered. Immutability helps here. Props/context are threaded all the way down. E.g the current light/dark theme ServerState should be subscribed individually by components that need it, and only the components looking at that state render. (E.g List of items from GET call, when you update the item, an update only needs to happen in that one place that keeps its data synced with server)