<story><title>Nunjucks – A rich and powerful templating language for JavaScript by Mozilla</title><url>http://mozilla.github.io/nunjucks/</url></story><parent_chain><item><author>bryanlarsen</author><text>What I&amp;#x27;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...&lt;p&gt;The closest I&amp;#x27;ve seen to what I want is DRYML:  &lt;a href=&quot;http://hobocentral.net/manual/dryml-guide&quot; rel=&quot;nofollow&quot;&gt;http:&amp;#x2F;&amp;#x2F;hobocentral.net&amp;#x2F;manual&amp;#x2F;dryml-guide&lt;/a&gt;&lt;p&gt;The big advantage of DRYML over systems like React &amp;amp; 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&amp;#x27;re instantiating.&lt;p&gt;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.&lt;p&gt;DRYML allows customization in both the small and the large.   It works well for both defining and customizing &amp;lt;a&amp;gt; tags as well as huge custom components.   That huge custom component will use your customized &amp;lt;a&amp;gt; etc, so it automatically picks up your theme and behavior.&lt;p&gt;DRYML has some major disadvantages though:  it&amp;#x27;s really nice to use, but defining new components looks like line noise.  It&amp;#x27;s also tied to a heavyweight, lightly used framework for Ruby on Rails called Hobo.&lt;p&gt;One of my many projects abandoned due to lack of time is a port of DRYML&amp;#x27;s &amp;quot;standard library&amp;quot; Rapid to React.   React isn&amp;#x27;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.</text></item></parent_chain><comment><author>adambard</author><text>The Enlive scraping&amp;#x2F;templating library for Clojure can be used in a pretty novel way to generate templates. I guess it&amp;#x27;s a bit like transforming XML with XSLT, except without the need for an intermediary language (in favor of a DSL in Clojure).&lt;p&gt;Templating with Enlive takes regular old HTML, which could even be mockups of your ui, and a list of (selector, transform) pairs to apply to it. The selectors mostly mimic CSS, while the transforms come with a library to manipulate node attributes, contents, etc. Taking a non-functional form and setting its method and action might look like this:&lt;p&gt;&lt;pre&gt;&lt;code&gt;    [:form#my-form] (enlive&amp;#x2F;set-attr :action &amp;quot;.&amp;quot; :method &amp;quot;POST&amp;quot;)
&lt;/code&gt;&lt;/pre&gt;
My favorite part of using enlive is that it removes almost all responsibility from any frontend developers to know about the templating. They can just produce straight HTML mockups with enough CSS hooks for you to get in and change what needs changing. I even use it on projects that I don&amp;#x27;t envision anyone else working on -- it&amp;#x27;s nice not to have to context-switch between design and development all the time.</text></comment>
<story><title>Nunjucks – A rich and powerful templating language for JavaScript by Mozilla</title><url>http://mozilla.github.io/nunjucks/</url></story><parent_chain><item><author>bryanlarsen</author><text>What I&amp;#x27;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...&lt;p&gt;The closest I&amp;#x27;ve seen to what I want is DRYML:  &lt;a href=&quot;http://hobocentral.net/manual/dryml-guide&quot; rel=&quot;nofollow&quot;&gt;http:&amp;#x2F;&amp;#x2F;hobocentral.net&amp;#x2F;manual&amp;#x2F;dryml-guide&lt;/a&gt;&lt;p&gt;The big advantage of DRYML over systems like React &amp;amp; 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&amp;#x27;re instantiating.&lt;p&gt;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.&lt;p&gt;DRYML allows customization in both the small and the large.   It works well for both defining and customizing &amp;lt;a&amp;gt; tags as well as huge custom components.   That huge custom component will use your customized &amp;lt;a&amp;gt; etc, so it automatically picks up your theme and behavior.&lt;p&gt;DRYML has some major disadvantages though:  it&amp;#x27;s really nice to use, but defining new components looks like line noise.  It&amp;#x27;s also tied to a heavyweight, lightly used framework for Ruby on Rails called Hobo.&lt;p&gt;One of my many projects abandoned due to lack of time is a port of DRYML&amp;#x27;s &amp;quot;standard library&amp;quot; Rapid to React.   React isn&amp;#x27;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.</text></item></parent_chain><comment><author>_wmd</author><text>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().&lt;p&gt;See e.g. &lt;a href=&quot;https://en.wikipedia.org/wiki/Template_Attribute_Language&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;en.wikipedia.org&amp;#x2F;wiki&amp;#x2F;Template_Attribute_Language&lt;/a&gt;&lt;p&gt;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&amp;#x27;t end up in a fight with your perfectionist templating system (and probably resorting to regexes over its output) to achieve the desired result.&lt;p&gt;I&amp;#x27;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.</text></comment>