A view’s responsibility — a lesson on JavaScript and the DOM

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.

Is the code meant to have entity characters encodings showing through? Love the post though - very thought provoking!