The author's point was that with Angular, the Angular module system you must use (you can't opt out), and you are most likely nowadays going to be using commonJ

The author's point was that with Angular, the Angular module system you must use (you can't opt out), and you are most likely nowadays going to be using commonJS or AMD anyway, so you end up with two module systems. At the time (in 2009) it probably made sense to come up with an Angular module system, but now that most people use require/webpack/browserify, it has become a hinderance. The reason being you can't just require() a module in a unit test, you have to bootstrap the entire Angular system and all angular modules, which is a huge pain for unit testing and causes all sorts of side effects. The other thing the author didn't mention is you can't debug your HTML templates. With Mithril, you can set a regular javascript breakpoint in your views. Directives and code-in-HTML essentially reimplement a half-assed version of JavaScript. (The same criticism applies to JSTL which throws out a perfectly good language, Java, and forces you to use XML and tag libraries.) HTML logic creates complexity because it invents a new programming language in the HTML. The code-as-HTML is the root problem that causes all the scope issues, all the explosion and complexity of directives, filters, and the inability to set breakpoints in views. With Mithril you don't have this whole directive/filters nonsense, you just write functions. I've written more about this subject at: https://medium.com/@l1ambda/mithril-vs-angular-vs-react-d0d659c24bae https://medium.com/@l1ambda/mithril-vs-angular-vs-react-d0d6...