Add native support for additional template engines #819

Closed
benbalter opened this Issue Feb 21, 2013 · 27 comments

Comments

Projects
None yet
Contributor

benbalter commented Feb 21, 2013

Jekyll is great for traditional blogs, but can be a bit of pain when used to create dynamic sites. Would be awesome to see native support for additional template formats beyond markdown (e.g., CoffeeScript, EJS, LESS/SASS). This could be accomplished by adding additional generators, or by moving to something like Tilt for template abstraction (which I don't believe will present any security concerns if implemented on GitHub Pages).

Simplicity should be the goal here. Ideally, Jekyll would just look to the file extension, e.g, .md continues to work as it does now, but .coffee could render into .js, etc. I don't know that a full fledged sprockets-style asset pipeline is in line with the project's core philosophy (and Middleman) or Jekyll plugins already provide the heavy weight path for power users), but simply adding support for additional template engines could really push Jekyll from a mere blogging engine to a more powerful static site generator, especially as folks increasingly look to it to build single page apps.

Related:

Contributor

trans commented Mar 3, 2013

I was just about to post an issue for the same thing. I think it would be good if Jekyll supported other markup formats too --basically all the ones that Gollum supports.

Owner

mattr- commented Mar 6, 2013

I don't see any problem whatsoever with supporting additional format options and it should be apparent from the response to #830 that we'll add contributed support for other formats such as AsciiDoc.

However, Jekyll is not a dynamic site generator. Therefore, I don't understand the need to support the template formats presented in this issue. Could you explain further why, given the additional plugins that are available, we would need support for things like CoffeeScript, EJS, and LESS/SASS in Jekyll core?

@ghost

ghost commented Mar 7, 2013

@mattr There's people that prefer to create their CSS/JS using Coffeescript and SASS instead. Adding support into the Jekyll core would make it easier for people to do.

Then again there's plenty of plug-ins to do it for you, so I don't particularly see the issue.

Contributor

benbalter commented Mar 7, 2013

+1 to what @xeross said.

Still would be used to generate a static site, but right now Markdown is given preferential treatment to other pre-processed formats. The idea would be I could write in .coffee which Jekyll would process to .js, just as .md is processed to .html.

As for plugins, yes, they exists, but (A) over complicate things with complicated asset pipelines which strays beyond the project philosophy, and more importantly (B) are completely off limits to folks using GitHub Pages (presumably the largest use case). Would allow GitHub pages to support more than just markdown and be a much more attractive engine for static site hosting.

sl4mmy commented Mar 7, 2013

#561 obviates (B): you could build your site locally with one config file with plugins enabled, and host the generated assets on GitHub Pages with a different config file without plugins.

Contributor

benbalter commented Mar 7, 2013

Fair point. Better articulating (B): it was my vision that we could make Jekyll more accessible to a wider swath of use cases if GH Pages supported pre-processors other than markdown.

Owner

mattr- commented Mar 7, 2013

Thanks for the explanations. I understand the issue much better now.

My POV on this is that it would be useful to have and I give a 👍 to having it. I feel that there's a little bit of a circular dependency here though. Jekyll tends to be safe by default in order to support the use cases for GitHub Pages. We advise people that need functionality that's not provided by safe mode to generate locally and then push the generated content. Can we get somebody from the GitHub Pages team to chime in on this issue? Their feedback would be useful to consider here.

Contributor

benbalter commented Mar 7, 2013

@sr - would you be the right person to weigh in by chance?

sr commented Mar 8, 2013

@benbalter I don't have an opinion on whether Jekyll should support more template engines or not. I am not suggesting that it isn't worth it or anything at all. The only thing I'd say is to keep in mind that Jekyll is used by a lot of people across github.com and new features means more things to support. Lurking on the support requests is interesting to get a feel of this stuff. Happy to help you 🚢 GitHub Pages changes otherwise.

Contributor

trans commented Mar 8, 2013

Is there any reason not to use Tilt? Isn't that a GitHub supported project too?

Contributor

tombell commented Mar 11, 2013

When people say 'more templating languages' do they mean being able to replace Liquid, or different markdown/textile renders? These are distinctly different in jekyll.

Contributor

trans commented Mar 11, 2013

My concern is for markdown/textile alternatives.

twe4ked commented Mar 19, 2013

I would love to see support for Sass in Jekyll purely so I could use it in conjunction with GitHub pages. Haml would also be great.

Contributor

benbalter commented Apr 1, 2013

So looking at #845, #199, and #830, it sounds like there are a handful of things that this approach can solve in a sane way (from a developer perspective) as the project continues to grow and mature behind a mere blogging engine.

It'd be really, really bad if this added complexity from a user perspective. Jekyll's all about zen-like simplicity, and that's what makes it attractive. If I had a choice of 50 rendering engines that I could add in my _config.yml file, like I can with markdown renders now (e.g., how do I as a first-time user know if I should use rdiscount or maruku?!), we'd really be shooting ourself in the 👞.

The goal should be make rendering internally more sane by leaning on existing gems, while not changing the user experience for existing (and future users). Essentially, take what we do with .md files now, and just scale that awesomeness to other formats. If I commit a file with a .coffee extension, it should just know that it needs to be .js by the time it gets to _site, just like .md automagically transforms to .html now. Super simple. Super transparent.

@sr great idea. Will lurk away.

siscia commented Jun 21, 2013

How it ended up ?

There are any chances to get support for asciidoc ?

jbaruch commented Jul 9, 2013

👍 on this, we want asciidoc/asciidoctor support.

Owner

parkr commented Jul 9, 2013

Soon. #1278.

Owner

parkr commented Feb 8, 2014

Tilt will not be included, however custom converters are (since pre-1.0, IIRC) and custom markdown processors are on master (but not in 1.x). Seems like most of this is satisfied.

@benbalter What are we still missing?

Contributor

benbalter commented Feb 8, 2014

CoffeeScript + Sass in core + a saner API to chain converting content sounds like a great first step.

Owner

parkr commented Feb 9, 2014

CoffeeScript + Sass in core

Done: #1991, #1932

a saner API to chain converting content sounds like a great first step.

You mean multiple converters per doc? Makes sense to me, definitely 👍 on that.

Contributor

benbalter commented Feb 9, 2014

You mean multiple converters per doc?

Sure? I'm using Emoji or @mentions as a typical use case in my head. I'd like to modify the post-markdown-converted content in some way.

getreu commented Feb 17, 2014

Will there be asciidoc/asciidoctor support in Jekyll 2.0?

Owner

parkr commented Feb 17, 2014

@getreu No plans to add it in the core, no. Is there an asciidoc plugin you can use?

getreu commented Feb 17, 2014

There is one: https://github.com/asciidoctor/jekyll-asciidoc

I am here because I am looking for a static site generator with asciidoctor support.

Pull Request #830: Add support for AsciiDoc powered by Asciidoctor
was closed in favour of another solution. Is this solution implemented?

+1 for core asciidoctor support

Owner

parkr commented May 5, 2014

We have plugin support on GitHub Pages and RubyGems isn't going to halt anytime soon. I think we're good on this.

@parkr parkr closed this May 5, 2014

pmackay commented Jun 30, 2014

It seems there are various places where HAML support has been mentioned, including here. What are the reasons why this has not been implemented alongside SASS and CoffeeScript support? Any insight would be useful for the record.

Owner

mattr- commented Jun 30, 2014

HAML can't be supported on GitHub Pages from a security perspective, so it hasn't been implemented.

@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.