
Nunjucks – A rich and powerful templating language for JavaScript by Mozilla - kolev
http://mozilla.github.io/nunjucks/
======
bsimpson
I love me some Python/Jinja/Flask/CherryPy, but after having written JS apps
in React that run seamlessly on the client and the server, I can't imagine
going back to something like this. The best case scenario, you have to
maintain a JS port of your app to support rendering your Jinja templates on
the client. Or, you can just use Node, Webpack, and React to serve a single
codebase that renders on either end. Save Python for your data API.

~~~
jquery
Why is the top comment on Hacker News always a nay-sayer? Not everyone is
working on greenfield projects. Nunjucks is a huge improvement for many large
codebases.

~~~
ezequiel-garzon
Well, right now there are three top-level comments, and the one you refer to
is the only one of those presenting more than a sentence. Also, it seems to be
no longer ranked first.

In any event, I must say I like this kind of comments: a bit opinionated but
putting forth some rationale, and hence inviting a healthy exchange of
opinions.

~~~
aikah
> and hence inviting a healthy exchange of opinions.

There is no "inviting a healthy exchange of opinions",he is basically just
trashing the project.There is nothing interesting in what he is saying,though
he's free to say whatever he wants.Proof is the answers to his comment.

------
bryanlarsen
What I'd really like to see would be a nice templating language that
recognizes and takes advantages of the regular structure of HTML rather than
just treats it as a giant string. Can you imagine writing a program using
string templating rather than functions, objects and libraries? Sure, it would
be possible, but it would be rather awkward...

The closest I've seen to what I want is DRYML:
[http://hobocentral.net/manual/dryml-
guide](http://hobocentral.net/manual/dryml-guide)

The big advantage of DRYML over systems like React & builders is that it has a
really nice story for customization. Rather than customizing just through XML
attributes, it also has a system for passing in snippets through XML children.
But not just snippets for the top component, but but snippets for children of
the components you're instantiating.

This has huge advantages for reusability. There are millions of jQuery widgets
out there. How come you never use any of them? They never fit the style,
behaviour nor requirements of your app. Yet on the server side, you pull in
tens of gems, npms, etc from random authors.

DRYML allows customization in both the small and the large. It works well for
both defining and customizing <a> tags as well as huge custom components. That
huge custom component will use your customized <a> etc, so it automatically
picks up your theme and behavior.

DRYML has some major disadvantages though: it's really nice to use, but
defining new components looks like line noise. It's also tied to a
heavyweight, lightly used framework for Ruby on Rails called Hobo.

One of my many projects abandoned due to lack of time is a port of DRYML's
"standard library" Rapid to React. React isn't quite as nice as DRYML for re-
use and customization, but it has a large number of advantages in popularity,
speed and readability. If anybody else is interested in the project, give me a
shout.

~~~
_wmd
There were a whole family of older template systems that worked on this model.
They suck because in practice they are much more restrictive, difficult to
work with, and in most cases inefficient, since fundamentally they are working
in the domain of a fully parsed node graph, instead of simply being
lightweight control structures for basically memcpy().

See e.g.
[https://en.wikipedia.org/wiki/Template_Attribute_Language](https://en.wikipedia.org/wiki/Template_Attribute_Language)

On the flexibility front, the same template language (and especially ones with
good whitespace control, e.g. Jinja2) can be used for any text-like format. If
browser or device quirks force you to emit invalid XML to trigger some desired
behavior, you don't end up in a fight with your perfectionist templating
system (and probably resorting to regexes over its output) to achieve the
desired result.

I'd say (and probably, a younger version of myself turns in his grave as I say
it) that in this case, worse turns out to be much better.

~~~
DonHopkins
TAL as it was implemented for ZOPE was a total abortion (especially when they
threw in other crap to make up for its gaping weaknesses like TALES, METAL,
and those goofy expression what were not anything like any other language,
plus "acquisition" which was a terrible and useless approach to scoping). The
ZOPE stack's approach to templating and scoping and components and their
entire way of thinking about it was totally demented and wrong headed. I used
it a lot in my wild and crazy ZOPE days, and I hated it then and won't ever go
back.

On the other hand, there are other similar attribute based xml templating
languages that are much much better, because they didn't try to reinvent the
wheel out of tapioca and rusty iron filings, but instead they simply acted as
a thin veneer over Python, so everything you knew about and could do in Python
applied without any distortion or unnecessarily creative reinterpretation.

Specifically, TurboGears used the "Kid" templating language, the next
generation of which was re-implemented as "Genshi". I have used both
extensively, and although they do have some problems and limitations (many of
which Genshi addressed), I really like them a lot, and they are easy to use
and think about, and not so full of surprises and disappointments as the
horrible stuff from ZOPE that they (distantly) descended from. I've used Kid
and then Genshi in large template-heavy projects over many years, and I still
use Genshi and like it. It is actually quite elegant and minimalistic, and
super easy to learn.

[http://genshi.edgewall.org/](http://genshi.edgewall.org/)

Genshi operates on pure clean XML internally, has real Python loops,
conditionals, variables, functions, parameter passing and extensibility, and
has plug-in serializers for various formats like XML, XHTML and HTML5, that
know about all the formatting rules and conventions and browser quirks and
superstitions like <BR />, and never produce incorrectly quoted or formatted
content. You can also use it to product plain text as well as markup.

------
riffraff
> “Nunjucks has allowed us to port all of our existing templates from a Django
> project to something that's easier to manage.

why is it easier to manage?

------
igl
Looks exactly like swig. Only the async operations are new.

[http://paularmstrong.github.io/swig/](http://paularmstrong.github.io/swig/)

~~~
masklinn
That's because both are Jinja reimplementations (given the name, I expect Swig
is a JS version of Twig[0], itself a PHP implementation of Jinja, and
originaly started by Armin Ronacher — Jinja's author[1][2])

[0] [http://twig.sensiolabs.org](http://twig.sensiolabs.org)

[1] [https://github.com/mitsuhiko/twig](https://github.com/mitsuhiko/twig)

[2] [http://fabien.potencier.org/article/34/templating-engines-
in...](http://fabien.potencier.org/article/34/templating-engines-in-php)

~~~
igl
Yes I figured that out. I just don't understand why this has to exist. It's
adding nothing noteworthy and very likely not faster either.

By the example of async which initiates value lookups... it can only be slower
and promotes the bad habbit of putting too much logic into views.

------
borplk
It would be interesting if the templating languages stopped being "for X
programming language".

I'd like to see a sane templating language that is based on a spec and it
could be supported under different programming languages.

~~~
aikah
> that is based on a spec

No,because your spec wouldnt suit everybody and you'll end up with 20 other
specs. That's why there is not just 1 programming languages.Because silver
bullets dont exist.

~~~
borplk
There's no problem with 20 other specs.

I didn't mean spec as in a universal standard.

I meant a language that defines its syntax and functionality as a spec so it
can be implemented in the same way in many languages so you can pick your
favourite flavour and use it in as many languages as you want without
surprises.

So given the template 'T' and template context 'C', you could always produce
the exact same output regardless of whether you used javascript or python
(assuming the libraries implemented the language based on the spec).

The spec doesn't mean it has to be a silver bullet, it will be a single bullet
and there will be many bullets, but whatever bullet you pick, you can use it
in more places.

------
8ig8
On the surface, this looks very similar to Twig, a PHP template engine also
inspired by Jinja.

[http://twig.sensiolabs.org/doc/templates.html](http://twig.sensiolabs.org/doc/templates.html)

------
serve_yay
Is this string templating? I can't find anything about that on the site. (I'm
guessing it is, if it can run on the server and the client.)

------
ts95
This reminds me a lot of the template language in Django.

~~~
bsimpson
Jinja is a reimplementation of the Djano language (but improved). This is it's
JS port. It's a spiritual successor to Django, ported to JavaScript.

~~~
vixin
This is its JS port.

------
judk
Another "ninja" name, pushing programming toward stereotypically
"dude/violent" interests for no reason.

