State management, for anybody half competent, is stupid easy and not tied to the UI. State management is a data storage/retrieval problem only. Once the UI has the state information it needs you can populate it for the user however you want in many different ways.
State management is also proclaimed as something it isn’t because web UI is full of incompetent expert beginners who can’t write two lines of original code and are helplessly mortified if their colossal framework is taken away.
Here is simple web UI state management:
* have a centrally available object in the UI code that stores state data.
* store that data upon change. That storage can be localStorage for maximum simplicity. It can also be a locally written file if you have a local running service or an http server. The further away from the local computer that storage location becomes the slower it is regardless of access mechanism.
* state changes can occur from user interaction or system updates to remote data. Most important are user interactions because that data is locally available. Keep up with remote system changes as best you can, but unless you own that data as well it’s a window into some distant concern.
* when state changes update your central state object save the changed state object. Most of the time UI developers are only concerned with state updates and not saving state because they don’t know what they are doing and hope the framework does everything (or it must obviously be unnecessary).
* once the state object is updated, and optionally saved, update the UI. For most UI developers updating the UI is the ultimate and only struggle. This is such a junior level basic required skill for UI developers. Knowing that you can root out the incompetent people during hiring.
But but but what about 2 way data binding... Treat it as an event. Update the central state store. Process the change. Still simple and no framework is needed.