Disclaimer: I'm the author of Mithril.js (one of said Javascript frameworks) Honestly I didn't find this article very good. For example, it says things like "R

Disclaimer: I'm the author of Mithril.js (one of said Javascript frameworks) Honestly I didn't find this article very good. For example, it says things like "RequireJS is one of the popular instruments for resolving dependencies... AngularJS goes a little bit further by giving us something called factory", which show some bias towards Angular, when in reality RequireJS is quite a bit more sophisticated (it allows you to bundle things offline and have async modules, for example), whereas Angular is just an IoCC (and the magic shorthand syntax is actually not recommended for production). Also disagree with this to a certain extent: "I like the idea of turning features off and on." Being able to turn things off is a bad default. Imagine joining a new team, and you write some code and it blows up because their underscore is actually not underscore but a shim missing half of the functionality. Also disagree with "The popular two-way data binding should not be a feature, but a must-have core functionality." Two-way data binding is expensive (and can get prohibitively so in a sufficiently complex page). There's a reason Angular people recommend not going over 2000 bindings on a page, and ironically out-of-the-box data binding solutions tend to completely ignore things like the event delegation model, which is a powerful performance tool (I wrote about it here http://lhorie.github.io/mithril-blog/asymmetrical-data-bindings.html http://lhorie.github.io/mithril-blog/asymmetrical-data-bindi... ). In general, I feel his experience with templating engines comes across as a bit shallow. For example, "The framework of the future should make us think only about the data and only about the markup. Nothing in between." This is idealistic. In reality people have deadlines and there's a large ecosystem of libraries that you simply can't ignore.