What code? The only stuff in there is to respond to changes in underlying data or pass click events to their rightful handler. Also, making something prettier, more readable, and easier to maintain seems like the opposite of obfuscatory, no?
This is code "each person in people" — once you go down the path of doing that kind of thing, the next thing people will ask for are filters, etc. and eventually half your business logic is in the "template" and half in the view code.
I would say that "each person in people" is a far cry from the type of logic in views normally frowned upon. What would you propose to be different in this case? Where does iteration of this type belong?
Check out mustache. It has things that can be used for iteration but it isn't explicit and you decide what actually happens at runtime in code rather than in the template.
The {{#array}}item{{/array}} syntax is functionally equivalent to and equally logicless as {{#each array}}item{{/each}}, only the latter (handlebars) has the benefit of being precompilable and easily extensible by frameworks such as Ember, Meteor, and the like.
They may be equivalent, however, the first version has the freedom to do what they wish, for example, what is represented by array may not be directly iterable or it may be filtered. Precompilation is available in a variety of languages for mustache, including js.
IMOH, handlebars is a lazy version of mustache where the developer using it sacrifices maintainability and encapsulation. Which is probably ok for most apps that don't grow beyond a single developer.
Comments
What code? The only stuff in there is to respond to changes in underlying data or pass click events to their rightful handler. Also, making something prettier, more readable, and easier to maintain seems like the opposite of obfuscatory, no?
This is code "each person in people" — once you go down the path of doing that kind of thing, the next thing people will ask for are filters, etc. and eventually half your business logic is in the "template" and half in the view code.
I would say that "each person in people" is a far cry from the type of logic in views normally frowned upon. What would you propose to be different in this case? Where does iteration of this type belong?
Check out mustache. It has things that can be used for iteration but it isn't explicit and you decide what actually happens at runtime in code rather than in the template.
http://mustache.github.com
The {{#array}}item{{/array}} syntax is functionally equivalent to and equally logicless as {{#each array}}item{{/each}}, only the latter (handlebars) has the benefit of being precompilable and easily extensible by frameworks such as Ember, Meteor, and the like.
They may be equivalent, however, the first version has the freedom to do what they wish, for example, what is represented by array may not be directly iterable or it may be filtered. Precompilation is available in a variety of languages for mustache, including js.
IMOH, handlebars is a lazy version of mustache where the developer using it sacrifices maintainability and encapsulation. Which is probably ok for most apps that don't grow beyond a single developer.
Hogan.js by Twitter is a mustache implementation that supports precompilation, among other things.