Proprietary attributes for templating are confusing. So confusing the author put the ng-repeat in the wrong place (I think).
Can someone familiar with angular explain how you would would make a special case '<li>There are no names in the list</li>'? It is obvious to me how to do it with ember, but non-obvious in angular.
Or, if you don't want the "no names" item in the list at all when it's inapplicable, instead of merely hidden:
<div ng-switch="names.length">
<ul ng-switch-when="0">
<li>There are no names in the list.</li>
</ul>
<ul ng-switch-default>
<li ng-repeat="name in names">{{name}}</li>
</ul>
</div>
Behavior can be provided through directives via elements, attributes, css class names, and comments.
It isn't "allergic to conditionals". It just drives the logic elsewhere to keep the presentation layer looking as clean as possible to the developer so that you can either focus on the view (template) or the controller or model.
I think you described exactly what I meant by "allergic to conditionals": a philosophy that conditional logic never belongs in the presentation layer. I didn't intend to imply a value judgement.
It's a judgement call. Some people are wary that going nutty with conditionals in templates could result in littering bits of 'business logic' in them - they prefer to take an all-or-nothing stance and go for nothing.
Personally I like the sort of middle-ground approach that Handlebars [1] has, I'm fine with basic 'truthy/existence' type checks, but will avoid templating languages that allow 'any old code'.
I think this sort of discipline (picking a deliberately restrictive library) is probably more useful for teams than individuals (who are capable of limiting their own conditional crazy).
Can someone familiar with angular explain how you would would make a special case '<li>There are no names in the list</li>'? It is obvious to me how to do it with ember, but non-obvious in angular.