Almost true. As someone who have been working on a complex desktop app for 4 years now. I found that state management solutions are always incomplete for the p

Almost true. As someone who have been working on a complex desktop app for 4 years now. I found that state management solutions are always incomplete for the problems we have in our team. When you say "stop acting like react", it is actually true that some mechanism needs to escape from React's render loop while retaining its tree-like structure. New members to the team will have to be introduced to the idea that an actor (object that acts on data) does not need to be the same entity as the React component itself. We end up taking a lot of concepts from other domains such as game engine, Rust's ownership/borrowing What we ultimately need are that's not fulfilled by many state management libraries out there: - Instead of global vs local, we need management of scope, referability, and intuitive dependency injection. - Instead of state, we need management of actors. - Management of lifetime, ownership, and borrowing (concept taken from Rust) - A differentiator between actor, function, and data (which entity should or should not do stuffs) - Two-way communication channel - A consistent code semantic that makes sense to describe it all because TypeScript/JavaScript does not cut it.