Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

Add native support for additional template engines #819

Closed
benbalter opened this Issue · 27 comments
@benbalter
Owner

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:

@trans

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.

@mattr-
Owner

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?

@xeross

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

@benbalter
Owner

+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

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

@benbalter
Owner

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.

@mattr-
Owner

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 :+1: 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.

@benbalter
Owner

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

@sr
sr commented

@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 :ship: GitHub Pages changes otherwise.

@trans

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

@tombell

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.

@trans

My concern is for markdown/textile alternatives.

@twe4ked

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.

@benbalter
Owner

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 :shoe:.

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 :sparkles: transforms to .html now. Super simple. Super transparent.

@sr great idea. Will lurk away.

@siscia

How it ended up ?

There are any chances to get support for asciidoc ?

@jbaruch

:+1: on this, we want asciidoc/asciidoctor support.

@parkr
Owner

Soon. #1278.

@parkr
Owner

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?

@benbalter
Owner

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

@parkr
Owner

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 :+1: on that.

@benbalter
Owner

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

Will there be asciidoc/asciidoctor support in Jekyll 2.0?

@parkr
Owner

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

@getreu

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

@parkr
Owner

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

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.

@mattr-
Owner

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.