[Discussion] Logic Free vs. Non Evaled

Mustache claims to be Logic-Free, while many other templating languages (e.g. Liquid) prefer to call themselves Non-Evaled. The question I'd like to raise is: what's the difference?

@groue says that "Logic-Free" and "Non-Evaled" are equivalent, and synonymous with "Code-Free" (where "Code" refers to the host language).

---

A clear line that both styles have chosen to draw is to deny direct access to the underlying programming language. {{ 1 + 2 }} is considered "unsafe" by both, in the same way that {{ FileUtils.rm_rf('/') }} would be. Similarly, neither permits the use of literal controls structures, making it impossible for a template author to produce a template that can disrupt the state of the data, the application, or the operating system -- both models can be considered to be "user safe" in that they don't require template authors to be trusted. This is the primary benefit I've heard discussed around Non-Evaled templating languages.

The primary claim I've heard around Logic-Free templating is that since your display logic cannot live in your templates, you're forced to relocate it elsewhere, where it can live out its life surrounded by other code (and where it can be more easily tested).

Mustache presently concedes on two points: conditionals and iteration. Iteration is perhaps less "logical", but allows for a more robust interpretation of the data. Conditionals are effectively a special case of iteration, where a truthy value is treated as a single element list, and a falsey value is treated as an empty list.

Summary:

Non-Evaling (Liquid)

• promotes "safe" templating
• enables plain-text (e.g. email) templating
• disallows execution of any code accessible from the data
• keeps executable code in a separate context
• encourages "procedural" templates and internal template state (e.g. via assign variables)
• allows basic literal types in templates as values

Logic-Free (Mustache)

• promotes "safe" templating
• enables plain-text (e.g. email) templating
• permits execution of code accessible from the data stack
• discourages internal template state
• has (should have?) no explicit order-dependency -- "declarative" templates

Open questions:

• Since Mustache has basic conditionals, what is the logic we're trying to prohibit in templates?
  • Database access?
  • Data construction?
  • Data manipulation?
    • Arbitrary data manipulation?
    • Predefined data manipulation?
• Do filters fit in that worldview?
• Do parameterized filters fit in that worldview?
• Do data literals fit in that worldview?
• Are there other significant differences between Logic-Free and Non-Evaling templates?

-- pvande

---

My take on why filters fit well in a logic-free template language: https://github.com/groue/GRMustache/blob/filter_chain/WhyMustacheFilters.md

-- groue

---

@groue, what I understood from your writeup is that you feel strongly that filters should be a part of the Mustache language, and that any definition of Logic-Free that precludes their possibility is unreasonably restrictive and user-hostile. Does this seem like a reasonable summary?

-- pvande

---

@pvande: basically, yes. Here is a longer explanation for you, dedicated repository maintainer: https://github.com/groue/GRMustache/blob/master/Articles/TheNatureOfLogicLessTemplates.md

-- groue