Good write-up and similar to some of my findings. In fact I like the event emitting / messaging pattern so much I wrote a little library called msngr.js (https:

Good write-up and similar to some of my findings. In fact I like the event emitting / messaging pattern so much I wrote a little library called msngr.js (https://github.com/KrisSiegel/msngr.js https://github.com/KrisSiegel/msngr.js) to do the same type of thing. I'm not entirely convinced of the separate "renderer" or really the act of updating a virtual dom but I do like the model-view-intent. What I've done is something pretty similar though typically I combine the model and the view in all cases but the main application itself. Basically the breakdown is like this: Application controller - initializes application components / authorization / anything necessary for startup Web components - Either through webcomponents.org polyfills or polymer these are the individual components that make up the user interface of the web application. Each web component is entirely responsible for its interaction with the user. It subscribes to messages when it should take in updates and it emits the data the user inputs. Application libraries - Handles the other end of messaging; has zero interaction with anything within the DOM. Subscribes to data that gets emitted from the web components and emits data that the web components need to display to the user. I try to keep things as basic as possible. I'm still experimenting and working on an example web application using msngr.js that I can actually release as open source but I am a fan of this type of pattern. The best part of this is I can do full unit testing on the application libraries with zero DOM and the web component side of things can be fully tested with mocked results.