Reactive MVC and the Virtual DOM

> Flux attempts to be reactive by making Stores listen to Dispatcher events, and Controller-Views listen to Store events. However, the centralized Dispatcher is imperatively controlled by Actions, rather than taking the responsibility to observe Actions.

This can definitely be disorienting since by default you use imperative APIs to create the actions, and then switch to working with events and subscribers from the dispatcher up until the re-render. I've not had too much difficulty with this, at least after some initial confusion.

> Flux dictates that inter-model dependency should live in the Dispatcher, but in MVI, those dependencies are defined inside each Model.

Maybe this should be edited. Flux stores are the analog of models, and each store can define which other stores have to finish updating before it responds to a given action (in that big case statement where it registers with the dispatcher).

The arguments for RxJS, testable view functions, and avoiding internal component state are important. The dispatcher being a singleton doesn't seem to affect much in practice, since that code is never really touched. Looks like performance could be better with virtual-dom but I'd be interested to see the different optimization strategies for each architecture and how they affect performance. Some of my own notes about optimizing React/Flux are here if you're curious: http://guscost.com/2015/05/27/react-js-and-flux-ideas-for-pr...

Also I think that reusable components is a really nice feature and I would encourage you to continue working on including this functionality. All in all a very nice piece, thanks for writing it up.

Interestingly, the sliders in the MVI example seem to react way more slowly...

Same for me.

> The gist is to frequently re-render a complete and lightweight representation of the DOM, then apply a difference filter to detect the minimum changes that need to be made to the DOM. A similar technique has existed in game development long before React: re-render the game screen in every game loop, but only update the minimum portion of the screen which changed compared to the previously rendered screen.

Practically every desktop UI works that way (Windows API, X Windows, Java UI libs). It's funny to see how web programming in 2015 slowly reinvents the wheels known since 1970s.

The browser that is rendering the DOM also, ultimately, works that way, with various portions of the browser screen redrawing while others remain static.

So it's kinda funny that the modern state of web dev is adding another layer of that same approach on top of layers of that approach.