Ember developer here and Ember is a strictly conventional MVC so I think I can possibly answer your question. From what I can gather its away to decouple yourself from the expectation of two way bindings and some of the issues it causes when the view is so entangled in the store/data structure. Being able to trigger actions and dispatchers that then go on to update a view is the what Flux (to me) is in a nutshell. Given the shadow DOM and the benefits of managed component rendering in React 16 (Fiber) I don't see how they can occupy the same development architecture. Having this dispatch and event pathway lets the components compute and render separately and that is ACTUALLY better for a front-end application in terms of render and load speeds. IMO: Two way bindings cause data store changes in such a closed loop that there is little possibility for the kind of innovation that React and the various stores are bringing to the table.