What is the programming rationale of logic-less templates (as in mustache/handlebars)? Why is purposely limiting the capabilities of the template language considered a good and desirable design pattern by the makers and users of these logic-less template libraries?

I've been working with node.js and handlebars lately on a small project and I find I'm regularly stymied by the lack of simple logic in handlebars templates.

Before I ditch the handlebars template engine in search of one that has greater logic capabilities, I'd like to understand the programming rationale behind using a logic-less template language.

I should clarify that I'm not asking for people's opinions on which kind of template language is better. I'm asking what are the objective reasons that people designed, built and use logic-less templates.

---

Here's a fairly simple example of what I would like the template to be able to handle by itself, but I don't see how in handlebars so I don't understand why it's considered a desirable characteristic that the "logic-less" template can't handle such a simple UI presentation by itself. Since there are a number of logic-less template choices, I am assuming there are useful reasons for it that I'd like to understand.

I have two variables from may app state that are passed to the template:

```
fanOn       // boolean: true or false
fanControl  // three states: "on", "off", "auto"

```

`fanOn` represents the current state on or off of some fans I am controlling
`fanControl` describes what kind of control mode the fans are in. "on" means they are turned manually on and will stay that way until further notice. "off" means they are turned manually off and will stay that way until further notice. "auto" means they are under automatic thermostatic/software control.

If the fans are on, I want to display a button to manually turn them off.

If the fans are off, I want to display a button to manually turn them on.

If the fanControl setting is on or off, I want to display a button to set it back to auto.

So, there's always a "Turn On" or "Turn off" button and if it's not in "auto" mode, there's a "Set Back to Auto" button.

There's no business logic here, it's just a matter of building the proper presentation based on the current state.

Here are various references I've found on the topic (which contain a combination of opinion and fact - a reader has to sort out which is which):

* [Enforcing Strict Model-View Separation in Template Engines](http://www.cs.usfca.edu/~parrt/papers/mvc.templates.pdf)
* [What are the benefits of logic-less templates like {{Mustache}}?](http://www.quora.com/What-are-the-benefits-of-logic-less-templates-like-Mustache)
* [The Case Against Logic-Less Templates](http://pswar.wordpress.com/2012/07/15/the-case-against-logic-less-templates/)
* [Cult of Logic-less Templates](http://www.boronine.com/2012/09/07/Cult-Of-Logic-less-Templates/)
* [Logic-less Template Redux](http://jmoiron.net/blog/logicless-template-redux/)
* [Your templating engine sucks and everything you have ever written is spaghetti code (yes, you)](http://www.workingsoftware.com.au/page/Your_templating_engine_sucks_and_everything_you_have_ever_written_is_spaghetti_code_yes_you)
* [Simple is better - Template Engines](http://www.simple-is-better.org/template/)
* [Mustache is logic-less but the logic has to go somewhere](http://www.javarants.com/2013/03/09/mustache-is-logic-less-but-the-logic-has-to-go-somewhere/)
* [3 Reasons to choose Logic Less templates like Mustache](http://www.connecto.io/blog/3-reasons-to-choose-logic-less-templates-like-mustache/)
* [Dust is eloquent – the logic wars - Paypal Engineering Blog](https://www.paypal-engineering.com/tag/template/)