I'm not familiar w/ React's implementation, so I can't speak for them. With Mithril, the diffing algorithm is basically a recursive tree diff. In addition to diffing at the attribute level (and taking care of some broken edge cases), it can do things like detect parent changes and reattach unmodified trees to new parents, if needed. I generally don't like corner-case-specific optimizations because I believe there are better directions to explore in order to improve performance (Mithril has a concept called SubtreeDirectives that I'm planning to expand on, for example). At the end of the day, one has to ask themselves if loading and parsing code to handle a bazillion rare corner cases is really significantly better than just doing the naive thing. The benchmark on the Mithril homepage seems to suggest that being minimalist performs better at the worst and arguably most important case (the first render).
Mithril in its entirety (with router, promises, ajax, etc) is ~500 lines of code (vs Bloop's 250) and the diff implementation has gotten more and more robust over the course of v0.1.* thanks to the Mithril community. I'd love to be proven wrong, but I'm seriously doubtful you can get a better balance between leanness and robustness elsewhere.
Re: best way to structure apps: I just posted an article ( http://lhorie.github.io/mithril-blog/an-exercise-in-awesomen... ) that ports some of the examples in this article over to Mithril to see how the two compared. My conclusion was that it's definitely possible to structure apps in a React-like style with Mithril. There a lot of benefits that this structure brings to the table, and using well understood design patterns effectively can go a long way to complement the componentization paradigm.
I don't force any particular implementation of the MVC pattern with Mithril, but I try to always organize code following the classic MVC pattern in my own code. My blog is partly an effort to document the techniques that can be used to support a liberal MVC pattern without necessarily committing to React's OOP paradigm or whatever.
I'm not familiar w/ React's implementation, so I can't speak for them. With Mithril, the diffing algorithm is basically a recursive tree diff. In addition to diffing at the attribute level (and taking care of some broken edge cases), it can do things like detect parent changes and reattach unmodified trees to new parents, if needed. I generally don't like corner-case-specific optimizations because I believe there are better directions to explore in order to improve performance (Mithril has a concept called SubtreeDirectives that I'm planning to expand on, for example). At the end of the day, one has to ask themselves if loading and parsing code to handle a bazillion rare corner cases is really significantly better than just doing the naive thing. The benchmark on the Mithril homepage seems to suggest that being minimalist performs better at the worst and arguably most important case (the first render).
Mithril in its entirety (with router, promises, ajax, etc) is ~500 lines of code (vs Bloop's 250) and the diff implementation has gotten more and more robust over the course of v0.1.* thanks to the Mithril community. I'd love to be proven wrong, but I'm seriously doubtful you can get a better balance between leanness and robustness elsewhere.
Re: best way to structure apps: I just posted an article ( http://lhorie.github.io/mithril-blog/an-exercise-in-awesomen... ) that ports some of the examples in this article over to Mithril to see how the two compared. My conclusion was that it's definitely possible to structure apps in a React-like style with Mithril. There a lot of benefits that this structure brings to the table, and using well understood design patterns effectively can go a long way to complement the componentization paradigm.
I don't force any particular implementation of the MVC pattern with Mithril, but I try to always organize code following the classic MVC pattern in my own code. My blog is partly an effort to document the techniques that can be used to support a liberal MVC pattern without necessarily committing to React's OOP paradigm or whatever.