Thanks for the time and effort you've put into this thread, it has been very interesting reading your comments, which have a lot of content and a lot of experie

Thanks for the time and effort you've put into this thread, it has been very interesting reading your comments, which have a lot of content and a lot of experience behind them. I wanted to ask you about this because I've been reading about when to use Redux and when not to, and I had basically come to appreciate that it would be helpful for the kind of app that I'm working on daily. That app is very complex and very dynamic, but because it is a desktop app there isn't a lot of routing since I can fit a whole lot on one screen. When there is routing, it's usually to another view with enough complexity and code for a totally separate SPA. So like I said, I've basically decided that Redux would be a great benefit for maintaining a consistent, easily debugged architecture for an app of this complexity, but then I came across several people talking about shared global state across routes as a good heuristic for knowing when Redux is appropriate. As mentioned, I don't really have that in my own app, so I was a bit confused by this and wanted to get some more details from you. I think you've cleared it up pretty well. I'm completely in agreement with you about the likely source of dislike and complaining for Redux. Absolutely people jump to it too often when it isn't necessary. More generally speaking, I think there's a default attitude that front-end should be easy, and then people are rudely surprised when they find out that it's actually very hard. Distributed systems problems, cache invalidation problems, combinatorial scaling of complexity with every feature and source of user interaction... you already know this. They blame the team or the tool, but there's a fundamental complexity there that's unavoidable and deserves respect. Anyway, thanks again, I've enjoyed reading your opinions on this.