7 ms·

Nunjucks – A rich and powerful templating language for JavaScript by Mozilla

108 points by kolev 12y ago

judk 12y ago
Another "ninja" name, pushing programming toward stereotypically "dude/violent" interests for no reason.
serve_yay 12y ago
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 12y ago
This reminds me a lot of the template language in Django.
- epicbird 12y ago
  It's inspired by Jinja (Python) so, yeah.
- bsimpson 12y ago
  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 12y ago
    This is its JS port.
- masklinn 12y ago
  They make no secret of it essentially being a JS implementation of Jinja > Rich Powerful language with block inheritance, autoescaping, macros, asynchronous control, and more. Heavily inspired by jinja2 And Jinja is an extended reimplementation of Django's template language.
riffraff 12y ago
> “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?
bsimpson 12y ago
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.
- Skywing 12y ago
  I've never worked on a larger javascript project, so I'm not sure why you'd care if your front-end js renders on the server (i'm assuming this means no visual browser). Is this for purposes of automated testing?
  - bsimpson 12y ago
    It gives you the best of both worlds: Non-JavaScript user agents, like search bots and scrapers, can still understand your page (as if it's rendered on the server), but you don't need to send redundant markup on each page view (because the client can render the new page with just a diff).
- bsimpson 12y ago
  If Nunjucks rendered performantly (like React), I could see the argument being made that it's the same upsides with an easier to read syntax (and should be thought of as an alternative from that POV); however, marketing it as a way to render your Python app in JS doesn't appeal to me for any new project.
  - bsimpson 12y ago
    To that end, I wonder if the virtual DOM aspect of React could/should be broken out into its own library. You could have different templating languages up front to suit different use cases/programming styles, but each would be converted to DOM in the fastest way possible by React's renderer. There are so many awesome things that React's model enables (like live editing with react-hot-loader). It would be awesome if the next generation of templating languages could inherit them for effectively free.
8ig8 12y ago
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
bryanlarsen 12y ago
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.
- judk 12y ago
  Try Yesod.
- Tloewald 12y ago
  I agree completely, which is what I did with my own binding library (which is supposedly going to be open-sourced in early 2015). The templating language is HTML (which can be viewed and styled normally) with a few custom data- attributes, the logic is Javascript. No extra silly half-assed languages to learn (aren't HTML, CSS, and Javascript enough?). The entire library is under 7kB minified (less gzipped) and does one-way (read-only) and two-way (live-updated) binding without changing the underlying object. To bind an object to a chunk of DOM (it leverages jQuery) you simple do something like $(selector).bindomatic(object) and you're done. (If you need additional logic, you pass it on the side in an options object.)
borplk 12y ago
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 12y ago
  > 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 12y ago
    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.
- davej 12y ago
  Mustache and Handlebars are pretty much that. They are available in most programming languages.
igl 12y ago
Looks exactly like swig. Only the async operations are new. http://paularmstrong.github.io/swig/ http://paularmstrong.github.io/swig/
- masklinn 12y ago
  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-php http://fabien.potencier.org/article/34/templating-engines-in...
  - igl 12y ago
    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.

108 points by kolev 12y ago

judk 12y ago

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

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 12y ago

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

epicbird 12y ago
It's inspired by Jinja (Python) so, yeah.
bsimpson 12y ago
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 12y ago
  This is its JS port.
masklinn 12y ago
They make no secret of it essentially being a JS implementation of Jinja > Rich Powerful language with block inheritance, autoescaping, macros, asynchronous control, and more. Heavily inspired by jinja2 And Jinja is an extended reimplementation of Django's template language.

riffraff 12y ago

> “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?

bsimpson 12y ago

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.

Skywing 12y ago
I've never worked on a larger javascript project, so I'm not sure why you'd care if your front-end js renders on the server (i'm assuming this means no visual browser). Is this for purposes of automated testing?
- bsimpson 12y ago
  It gives you the best of both worlds: Non-JavaScript user agents, like search bots and scrapers, can still understand your page (as if it's rendered on the server), but you don't need to send redundant markup on each page view (because the client can render the new page with just a diff).
bsimpson 12y ago
If Nunjucks rendered performantly (like React), I could see the argument being made that it's the same upsides with an easier to read syntax (and should be thought of as an alternative from that POV); however, marketing it as a way to render your Python app in JS doesn't appeal to me for any new project.
- bsimpson 12y ago
  To that end, I wonder if the virtual DOM aspect of React could/should be broken out into its own library. You could have different templating languages up front to suit different use cases/programming styles, but each would be converted to DOM in the fastest way possible by React's renderer. There are so many awesome things that React's model enables (like live editing with react-hot-loader). It would be awesome if the next generation of templating languages could inherit them for effectively free.

8ig8 12y ago

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

bryanlarsen 12y ago

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.

judk 12y ago
Try Yesod.
Tloewald 12y ago
I agree completely, which is what I did with my own binding library (which is supposedly going to be open-sourced in early 2015). The templating language is HTML (which can be viewed and styled normally) with a few custom data- attributes, the logic is Javascript. No extra silly half-assed languages to learn (aren't HTML, CSS, and Javascript enough?). The entire library is under 7kB minified (less gzipped) and does one-way (read-only) and two-way (live-updated) binding without changing the underlying object. To bind an object to a chunk of DOM (it leverages jQuery) you simple do something like $(selector).bindomatic(object) and you're done. (If you need additional logic, you pass it on the side in an options object.)

borplk 12y ago

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 12y ago
> 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 12y ago
  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.
davej 12y ago
Mustache and Handlebars are pretty much that. They are available in most programming languages.

igl 12y ago

Looks exactly like swig. Only the async operations are new. http://paularmstrong.github.io/swig/ http://paularmstrong.github.io/swig/

masklinn 12y ago
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-php http://fabien.potencier.org/article/34/templating-engines-in...
- igl 12y ago
  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.