We all know that real business logic does not belong in the presentation layer, but what about simple presentation-oriented things like coloring alternate rows in table or marking the selected option in a <select> dropdown? It seems equally wrong to ask the controller/business logic code to compute these down to simple booleans in order to reduce the logic in the presentation template. This route just lead to polluting the business layer code with presentation-oriented logic.

Templates with logic versus "logic-less" templates is a hotly debated point among template language designer and users. Dust straddles the divide by adopting a "less logic" stance.

Arguably, it leans into JSX land—including logic in the templates.

Also a vote against, for the simple reason that logicless templates would be the ultimate goal for me.

one of the reasons people sometimes balk at mustache-like syntax is just that: logic in the templates.

Writing a logic-less template requires a bloated view model with comprehensive getters for the raw data. As a result, a messy and difficult-to-maintain view model usually accompanies logic-less templates.

Full-of-logic, logic-less, and less-logic solutions

that does not mean that I am advocating the other extreme–i.e., a templating language that allows a lot of logic. I find such templating languages, especially those that allow the host programming languages to be used inside the template, to be hard to read, hard to maintain, and simply a bad choice.

Mustache is described as a "logic-less" system because it lacks any explicit control flow statements, like if and else conditionals or for loops

Here, when x is a Boolean value then the section tag acts like an if conditional, but when x is an array then it acts like a foreach loop.