One thing that raise my eyebrows about this article though is how says that Flux eschews MVC, and then goes on to say that it has stores that are "somewhat similar to a model", and "the dispatcher exposes a method that allows a view to trigger a dispatch to the stores", which, as far as classic MVC goes, is the exact definition of a controller. What they call controller-view is, imho, just an implementation detail within the view layer: in classic MVC, views were responsible for subscribing to model observables, or, as the article puts it, it "listens for events that are broadcast by the stores that it depends on".
When talking about this architecture with the Mithril community, I find that referring back to the MVC pattern makes it even easier to reason about the flow of data: it's basically M -> V -> C -> M ...
It's unfortunate that the general understanding of the MVC pattern became misunderstood over the course of many frameworks. The whole point of design patterns should be that we could just name them for people to "get" it, rather than having to reinvent new ways of naming things and having everyone relearn the nomenclature.
One thing that threw me off was startComputation() / endComputation(). It seems you have to be explicit about when properties are being updated for views to update. I worry this might be error-prone vs react.js - if you forget an endComputation(), or an exception occurs outside of a try/finally, your views will freeze forever, no?
Generally, you only need to manually call start/endComputation when integrating to 3rd party code that needs to update Mithril managed bindings.
In the latest release, I tweaked the rendering aggressiveness to allow redraws after exceptions in event handlers, and I updated the docs wrt `try/finally` blocks in integration scenarios.
One other thing people could do that I don't think should go in Mithril core is to call m.redraw inside window.onerror.
Of course, I'm open to other suggestions, if you have any.
I imagine this could have a significant performance impact, but don't know the mithril internals well enough to say.
EDIT: Thinking about it, the virtual DOM must be re-constructed on every redraw since the props aren't tied to a view. This probably wouldn't work well then.
As far as redrawing impact goes, Mithril does rate-limiting, so even attempting to subvert m.prop to force it to spam redraws should still perform ok.
To address your second comment: One distinction between the dispatcher and controllers in the MVC framework is that the dispatcher generally doesn't contain any business logic. It's essentially a hub for passing messages through: all sources of changes get funneled through the dispatcher, and the stores listen for those events, but the dispatcher doesn't actually modify or initiate the events. In my talk, I described it as the traffic controller of the system, which might be a more appropriate description.
As things get more complicated, the dispatcher may do more things at the framework level (Bill refers to the dispatcher handling dependencies between stores), but it stays separate from the application logic. In other words, we use the same dispatcher for multiple apps, so it plays a different role from the controller.
Hope that clarifies a bit, I'll see if we can make this distinction clearer in the documentation :)
It sounds to me like Flux goes with a model layer that handles all state (internal to the app and not), pushes most binding between pieces of the UI to the view layer, and uses a thin controller layer to mediate the other two layers and coordinate parts of the model layer with overlapping concerns.
I once had the epiphany that an entire web app is pretty much a whole bunch of nested or concatenated MVCs. I think the confusion arrives when people assume that there is one-and-only-one MVC and try to shoehorn all the parts of a new workflow into that rigid structure. I don't think that the proliferation of acronyms purporting to be something different helps with understanding.