A view’s responsibility — a lesson on JavaScript and the DOM | Hacker News Reader

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

open.bekk.no

70 pointskjbekkelund13 comments

The blog appears to be down. You can also read it at https://github.com/kjbekkelund/writings/blob/master/publishe... (I'm the author)

Edit: The blog appears to be up again! Hopefully it'll stay up this time ;)

> No frameworks or libraries are needed, just being strict with how you write your code.

No framework or library is needed, but they help. And at ~5k both Backbone and Spine's DOM-management object (resp. View and Controller) provide exactly the behavior (and shortcuts) you talk about.

I know, the point is just showing that the abstractions themselves are quite simple. I've used Backbone on several projects myself. Maybe I'll add a note at the end.

Edit: Added! Thanks. I should absolutely have added that before posting it.

> I know, the point is just showing that the abstractions themselves are quite simple

Aye, absolutely, just wanted to nitpick on that statement: while it is technically true (still the best kind around), it can be... not sure what the word is, not quite misleading but it can cause people to waste time not using a library when a small one would do that job (and others) for them.

It's absolutely great that you clearly documented the "pattern" as it is a vital one to retain one's sanity, it's just that this phrase sounded like an unwarranted objection to libraries doing the exact thing you recommend :)

Can you be specific on how they help? I've tried them many times and I don't see the fuss. I like bits and pieces of them. Backbone events is nice. I use something similar in a lot of my projects.

They provide all the tools TFA suggests/recommends and more[0], strongly shifting incentives towards a view only manipulating its own DOM (which becomes as cheap as or — in some case — cheaper than manipulating the global DOM).

[0] for instance both Backbone and Spine provide a declarative mapping of events triggered within a view's DOM to a method of that view, making handling of events arising from one's DOM much easier than handling events from outside; Spine also provides a mapping for sub-elements of a view's DOM automatically setting them on attributes of the view making DOM manipulation itself simpler.

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.

I put together some similar thoughts on client side code organization a while back: http://happybearsoftware.com/client-side-field-notes.html

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

What you get is loosely coupled, highly testable (and fast tests, since dom stuff is all in memory) ui code.

Absolutely. To focus the blog post I didn't go any further, but I plan (at some point) to write a blog post going deeper into how (I think) views should work.

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

Thanks. Are there still more entity character encodings left? I had a fight with Wordpress and it took some time to get everything working properly.

Reply on news.ycombinator.com