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

Strict/non-strict syntax modes #344

Closed
bgmort opened this issue Dec 23, 2014 · 3 comments
Closed

Strict/non-strict syntax modes #344

bgmort opened this issue Dec 23, 2014 · 3 comments

Comments

@bgmort
Copy link
Contributor

bgmort commented Dec 23, 2014

There seem to be two big reasons people use nunjucks over competing template engines: for Python/Jinja compatibility, or because it's the best javascript-powered template engine around. While jinja compatibility seems to be a priority, a lot of useful improvements could be made for nunjucks as a javascript library that would not be jinja compatible, but help it be the best possible template engine for javascript. That's why I want to throw out the idea of having a 'strict' mode that is on by default, but when turned off, would allow language features that are not a part of jinja. For example, in non-strict mode, the familiar &&, ||, and ! operators could be used instead of and, or, and not. The ternary operator could also be used instead of Python's odd .. if .. else .. syntax. I think this could go a long way toward making nunjucks the template engine of choice for the growing numbers of all-javascript projects.

@garygreen
Copy link
Contributor

I'm not sure this would really add much value. We do aim to have as close API/syntax to jinja as much as possible, so adding && || !, although familiar to javascript, would potentially polute and confuse, having multiple ways of doing the same thing. -1 for me

@ArmorDarks
Copy link

I must agree with @garygreen

👎 for me too

If someone wants Nunjucks features with JS operators — it's always possible to make fork.

@eddywashere
Copy link

As someone new to nunjucks and switching from swig, this would have been incredibly valuable. Instead I spent a lot of time figuring out what wasn't supported. Please consider revisiting this option, as it would be great for first users and people coming from swig. I would -1 to forking because that does not help the community. It only dissolves it.

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

5 participants