I've thought a lot about this topic because of the pains I've experienced w/ bad MVC, and because of the work I'm doing with my own MVC framework Mithril ( http

I've thought a lot about this topic because of the pains I've experienced w/ bad MVC, and because of the work I'm doing with my own MVC framework Mithril ( http://lhorie.github.io/mithril http://lhorie.github.io/mithril ). I wrote about some of my thoughts here ( https://groups.google.com/d/msg/mithriljs/WOvJARwmOYA/ovA_HVTawnQJ https://groups.google.com/d/msg/mithriljs/WOvJARwmOYA/ovA_HV... ), here ( http://lhorie.github.io/mithril-blog/an-exercise-in-awesomeness.html http://lhorie.github.io/mithril-blog/an-exercise-in-awesomen... ) and in the Mithril site ( http://lhorie.github.io/mithril/practices.html http://lhorie.github.io/mithril/practices.html ). My approach to it has been to avoid implementing design patterns as classes as much as possible - after all, doing so misses the whole point of design patterns. I'm spending a lot of my time now writing about the MVC pattern as a conceptual entity and documenting coding techniques, with the goal of putting the architecturing and engineering responsibilities back in developers' hands (as opposed to doing it for them inside the framework... and failing like everybody else) It's a bit disheartening that there's so many people jumping into the latest AngularJS education bandwagon, but almost no one bothers to try teaching the age-old underlying concepts that are actually valuable and that people can use for the rest of their careers. I'm hoping to help correct that with my work on Mithril and the blog.