New templating engine #704

Closed
parkr opened this Issue Dec 25, 2012 · 13 comments

Comments

Projects
None yet
9 participants
Owner

parkr commented Dec 25, 2012

Handlebars might be better, but it could also be preference.

If there were a way to specify a templating engine sort of like how we specify a markdown parser, that'd be the easiest way to keep everything somewhat backwards-compatible.

More discussion in #692, but post new comments here.

Member

ixti commented Dec 26, 2012

I guess you meant mustache. Handlebars is a mustache-alike template engine for JavaScript, not Ruby. And, to be honest, it's not differs from liquid a lot (in syntax) but allows to execute some ruby, which is not secure for GitHub pages IMO.

What I would really like to see is ability to use tilt or temple (which in it's turn provides ability to render any template language) in a non-safe mode (when I build website locally), so that I could use SLIM for my layouts.

Looking at this from 5-miles up, with extensibility in mind, this hotspot looks a lot like the Markdown engine hotspot.

For lurkers, I use "hotspot" as so-well described in Patterns for Object-Oriented Software Development by Wolfgang Pree.

So as we think about this, both these hooks should be extensible in exactly the same way. And it's good to know that by hooking one, the second could come along for free.

At any rate, a unary non-iterating and non-wrapped juncture here would be an underachievement.

Contributor

qrush commented Dec 26, 2012

I'm strongly 👎 for using anything but Liquid for templates. If you need more than Liquid, then you need more than Jekyll can offer you, IMO.

Member

ixti commented Dec 26, 2012

@qrush I partially agree with you :D I was voting for SLIM just because it produces one-line HTML which makes site footprint smaller. On another hand, as most of servers use gzip, this reduce might be really not as signification as I'm trying to show off it now :D

Owner

parkr commented Dec 27, 2012

@qrush If we could avoid this by using a different templating engine, that'd be swell. Why does Liquid stand out above all others in your mind? I'm curious as to why it should be the only templating engine offered.

baldowl commented Dec 28, 2012

@parkr I'm not going to speak for @qrush and I'm not going to say that Liquid should be the only template engine supported by Jekyll (even if advocating for a reduction of supported Markdown engines and, at the same time, thinking of multiple template engine looks like a contradiction to me), but dumping Liquid for, let's say, Mustache would allow us to avoid what you clearly despise only because a logic-less template engine would force us to move that logic somewhere else, obviously.

Another rather obvious effect would be that we who use Jekyll on GitHub Pages could forget to host our simple sites/blogs (which maybe use just a bit of logic thanks to Liquid) on it because that "somewhere else" would be something like current plugins, which GitHub cannot allow us to run for obvious security reasons.

Contributor

qrush commented Dec 28, 2012

I don't see why Octopress' variables should have any bearing on this discussion. Jekyll to me has always been "just dynamic enough" while remaining static. I honestly haven't seen anything better than Liquid for this kind of thing.

Member

ixti commented Dec 28, 2012

👍 @qrush

How about Hogan?

Contributor

qrush commented Dec 28, 2012

@kevinSuttle That's a JS library?

I motion to close this issue. @mojombo any objections?

"Hogan.js is a compiler for the Mustache templating language. For information on Mustache, see the manpage and the spec." It would be a means to a Mustache-y end.

@parkr parkr closed this Dec 29, 2012

Contributor

erlend-sh commented Sep 26, 2014

Might this be re-evaluated in light of the 3.0 rewrite #2636? I think a single templating engine is best, but the support for others could be improved, as indicated by jade-jekyll-plugin:

Jekyll doesn't yet allow plugins to pre-process layout files before further processing. To write your layouts in Jade, you therefore have to render them externally.

p.s. the link to the Octopress variables.html no longer works, so a pretty essential part of this conversation is missing.

+1 for allowing Jade to be used on layout files. It would make it so much easier to use Jade for all Jekyll projects.

@jekyllbot jekyllbot locked and limited conversation to collaborators Feb 27, 2017

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.