Well, I remember all these things just too well from our Backbone App (not Backbones fault, but ours!), and I would never go back there again. So now I have 3

Well, I remember all these things just too well from our Backbone App (not Backbones fault, but ours!), and I would never go back there again. So now I have 3 things to add to A and to B, because B needs to refresh everytime A does We used to do this. A lot. It was a big mess. Because in reality (for us), it is never that clear cut. You almost never have full dependencies so that thight coupling is the right way to do model it. There are always exceptions that you need to be aware of. We found that decoupling reduces cognitive load greatly, and changing the relationships can be done a magnitude quicker because "listen to except if this and that happens" doesn't scale. There are just too many this and thats if your app is big. I know that the status quo method always looks easier than something new, because its unfamiliar. But restriction of communication flow is, in my opinion, the ONLY way to keep order in a big, complex app. Just consider this: I've tried both ways extensively, and I favor the Flux way. I might be an idiot, but there is a possibility that I'm not. This should encourage people to really try this once to avoid status quo bias.