The blog appears to be down. You can also read it at <a href="https://github.com/kjbekkelund/writings/blob/master/published/views.md" rel="nofollow">https://github.com/kjbekkelund/writings/blob/master/publishe...</a> (I'm the author)<p>Edit: The blog appears to be up again! Hopefully it'll stay up this time ;)
Agree with this on multiple levels, though in practice I find a lot of codebases where views directly call events on passed-in model objects. In simple applications I find the extra level of indirection isn't worth it.<p>I put together some similar thoughts on client side code organization a while back: <a href="http://happybearsoftware.com/client-side-field-notes.html" rel="nofollow">http://happybearsoftware.com/client-side-field-notes.html</a>
I've always wondered why it wasn't possible to send a message to an object directly in Javascript. Here, you need to emit the message for EventEmitter to relay it back to the receiver. Though I guess there are benefits to this model as well, like a more centralized control of the whole flow of execution, possible message translations and composition.
I came to the same conclusion awhile back. Also, if it is in any way possible, a view should be able to write its own HTML (the rails worl has a concept of JSTs, not sure if that has filtered out yet), and a view should never insert itself into the dom<p>What you get is loosely coupled, highly testable (and fast tests, since dom stuff is all in memory) ui code.