Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Choose template engine #2

Closed
5 tasks done
ThaNarie opened this issue Feb 25, 2017 · 4 comments
Closed
5 tasks done

Choose template engine #2

ThaNarie opened this issue Feb 25, 2017 · 4 comments

Comments

@ThaNarie
Copy link
Member

ThaNarie commented Feb 25, 2017

Goals:
To render and preview components and pages, we don't want to duplicate elements across different HTML pages, so we want a template system that can include partials.

What to look for in a template system:

  • Needs to be as close to normal HTML as possible, since it will be copy/pasted into a CMS
  • Needs to support partials so we can re-use code without duplication
  • Needs to support dynamic data (variables), so we can re-use partials and preview a section with different data
  • Needs to support loops and conditional rendering to render dynamic parts and to prevent duplication
  • Needs to support dynamic partial includes, so we can render dynamic pages based on JSON data

Open for discussion

  • The assumption is made that the original development templates will be used by the backend party when integrating the templates in the CMS. When using plain HTML this is easier. If we use dynamic data and blocks/loops in the templates, it's easy for them to see how it's used since they probably need to do the same in the CMS or backend template engine. However, if we ignore this fact and just present the rendered HTML (either as full page or per component/section), we would have more choice, and could also look in the static site generator domain as an alternative.

Highlighted template engines:

Pug (formerly know as Jade)
We need our templates to be usable, so it must be plain HTML. Pug uses different syntax, so not useful.

Mustache / Handlebars
Easy {{ }} syntax. Handlebars adds some extra features (like blocks and helpers) that might be useful. We would probably only use a limited set of features.

nunjucks
Nice syntax, looks a bit like twig.

ejs
Oldskool and 'ugly'

twig.js
JS port of twig. Feels experimental, but has good support and usage. Maybe weird to use a JS solution if we're going for twig. Has benefit of easy integration in PHP projects if we choose this.

Pre-render or serve via express?

Are we going to pre-render our templates and view them as HTML files, or are we using express to view them? I guess pre-rendering makes more sense since we need to deliver HTML files anyway?

List of supported template engines by express (if we want to use that to render/preview)

Might want to put the discussion in a separate ticket, this was only added in case it would influence the decision for a specific template engine.

@pigeonfresh
Copy link
Contributor

My personal preference would be either Handlebars or Mustache. I think the helpers are really usefull. Twig might be a better pick for Drupal projects, but I'm not sure if the Drupal team uses Twig instead of PHPTemplate.

@ThaNarie ThaNarie mentioned this issue Feb 26, 2017
7 tasks
@ThaNarie
Copy link
Member Author

ThaNarie commented Mar 5, 2017

In the initial setup I've chosen Handlebars, and seems to work quite well.
There is an excellent webpack loader for handlebar templates, so they can be used during dev from the JS side, as well as during page generation for a dist build.

@ThaNarie
Copy link
Member Author

I also created a branch where I implemented a Twig version:
https://github.com/mediamonks/muban/tree/feature/twig

This is not ready to be merged, but instead should be used to create a setup where you can switch between the two.

As far as I can see both implementations are very compatible, but have slight differences in how to use at a template level (mostly on how to work with context/scope).

I had to rewrite most of the twig-loader to get it correctly working with webpack resolving and dynamic templates. I have opened a PR there, and currently the twig branch is linked to my Fork with those changes in place.

Having implemented two template engines now, I think it's safe to say that if a template engine has hooks for resolving files, and have a compile and render function for the templates, I am able to create a loader for it.

We might also want to look at RazorJS to support .NET sites, but I would have to create a webpack loader for it. The project is 4 years old and not that active, but that could also mean that it has nog bugs or doesn't need new features :P.
Another option for .NET sites is that they implement a Handlebars viewEngine.

@ThaNarie
Copy link
Member Author

ThaNarie commented Mar 7, 2018

I'm closing this, since most of the setup is fairly tightly coupled with Handlebars (would create a lot of duplication to support other template engines).

For converting handlebars to other languages, the muban-convert-hbs package is created.

Also, we have a setup in the works that uses the source hbs templates as-is in Twig.

@ThaNarie ThaNarie closed this as completed Mar 7, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants