Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Logicless or not? #1119

Closed
taras opened this issue Oct 16, 2015 · 4 comments
Closed

Logicless or not? #1119

taras opened this issue Oct 16, 2015 · 4 comments

Comments

@taras
Copy link

taras commented Oct 16, 2015

I've seen several videos where @wycats mentioned that Handlebars was not intended as a logicless templating engine but README says: "Handlebars.js and Mustache are both logicless templating languages that keep the view and the code separated like we all know they should be".

For the sake of clarity, is this description still accurate?

@kpdecker
Copy link
Collaborator

Logicless has not clear definition. I've seen arguments that claim once you have iteration and conditional branches, you are no longer logicless. I'd argue that you don't really have a useful template language with such a strict definition. Handlebars takes steps to avoid the business-logic in templates nightmare that was so often seen in early JSP and PHP days, but we have no control over the code that is run in helpers, by design, so you may argue that that is not logicless.

@kpdecker
Copy link
Collaborator

@wycats feel free to represent your own comments here :)

@wycats
Copy link
Collaborator

wycats commented Oct 16, 2015

The intention of Handlebars has always been to allow template authors to create their own control flow constructs outside the templating engine, rather than embedding the logic inside the templating engine.

The reason for this is that embedded JS drags with it the baggage of the full JavaScript language, while Handlebars helpers are expressly intended to be much more "pure". While I would never force every Handlebars (or Ember) user to understand the concept of purity, creating a new, limited expression syntax nudges people down the right path naturally.

One of the nice consequences of this is that it has been easy to port Handlebars to a lot of different languages, because the Handlebars expression syntax is designed to separate the core semantics from call-outs into the host language. This means that other embeddings need to expose a mapping from those call-outs into Handlebars semantics, but that's it.

@taras
Copy link
Author

taras commented Oct 16, 2015

Got it, thank you for the explanation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants