While Flux advocates for a totally new application architecture, it's one that still seems to fit the MVC architecture, especially when expressed using reactive

While Flux advocates for a totally new application architecture, it's one that still seems to fit the MVC architecture, especially when expressed using reactive concepts. I wrote a similar blog post to this one except using Elm as the reactive system[0], D3 for composable views[1], and MVC as the application architecture[2]. Once you have a reactive system and a declarative representation for your interface, applications get much easier to build. Decentralized state and event handling is secondary to those two concerns, and frankly of dubious value: once you start using lense-like things to help manage the distributed state, you're still going to run into issues where the lens isn't expressive enough to to handle certain operations (deleting an item from a list, for example), forcing you to either change your model so the lens is expressive enough, or dispatch events to a centralized location to handle the change. So the choice is either decentralize things and mangle your model, or keep things centralized. [0]: http://elm-lang.org http://elm-lang.org [1]: https://github.com/seliopou/elm-d3 https://github.com/seliopou/elm-d3 [2]: http://computationallyendowed.com/blog/2014/07/20/reactive-mvc.html http://computationallyendowed.com/blog/2014/07/20/reactive-m...