Hugo Templating: Not this. Again. ... Move templating to TAL. Please!

1st of all: Hugo looks good. Great, in fact. Really interersting and definitely a move away from the norm.

To the point:
Templating is bad in Hugo. It’s at Smarty level bad. Ever since Zope/Plone came out with TAL 15 years ago I consider any other method a waste of time and energy - especially so for static website generators. Am I really expected to write that kind of logic for simple templating with mustaches all over the place and convoluted structures? Today, in 2016? Back in 1999 we didn’t know any better but we should do now - especially with Go being a language that does everything so modern, efficient and simple to use.

I beg you devteam to drop whatever templating you have (it is a waste of time) and move to a TAL concept inmediately - it would do so much better. And it would fit snuggly into Hugos overall concept.

This is a humble request from someone doing web professionally.

That aside, thanks for the great project - awesome work guys!

1 Like

What is TAL? (I know you provide a link, but I’m lazy)

Hello @modparlor,

thank you for your feedback. The design of a templating language can be subjective and it’s understandable that some users prefer a different syntax. However, out of the box Hugo supports Go’s own templating language.

If it doesn’t seem to be intuitive in your eyes it would be more a critique towards the core developers of Go. Alternatively, Hugo also supports Ace and Amber templates. Both are very similar to the popular Jade templating language.

Syntactically, this is the status quo of Hugo. I searched Github and googled for Go projects that provide TAL support but I found none.

1 Like

@modparlor I don’t agree, but I see your frustration. Go Templating is definitely a little different from other templating languages and therefore potentially poses some unique challenges (not insurmountable, however - this community is incredibly helpful) for people familiar with other syntaxes. That said, I’m not sure I follow this comment:

“…write that kind of logic for simple templating with mustaches all over the place…”

This barely skims the surface, but every one of these is similar in its use of moustache/django double curlies:

I’ve never seen templating similar to TAL, and from what I can glean, Hugo can offer you at least everything you’re able to do in a TAL-based language. Could you maybe point to some SSGs that use this paradigm? Keep in mind that simplicity often means power (and perf!), so I’d be interested to see if something higher-level can compete with Hugo’s ≈.7 ms/page builds.

Although TAL (or even the above) might seem easier to grok on first glance, you might find yourself hitting walls in terms of functionality. From what I can tell so far, learning go templating is worth the investment. Hope that helps.

(wow, it’s been a long time since I laid eyes on TAL)

I guess Genshi in python is something along the same lines - if the main “feature” is that the markup can be understood and used with attributes


  <li py:for="i in mylist">${i}</li>


For anyone interesting in adding TAL support to Hugo (that excludes me), there’s a Go implementation of TAL at

1 Like

Is there real demand for this? I’m for whatever is easiest for newbs, but maybe the focus would be better spent bolstering Hugo templating on top of go templates…it’s not insurmountably difficult to learn the existing templating, and with 16, there are also a lot of great improvements, from what I can tell…

1 Like

A project with 9 stars on GitHub may be good enough; we had this discussion before, and for new template engines to get fitted into Hugo, they must (or should) integrate with Go templates – similar to Amber and Ace.

Another +1 for plugins! :wink:

+2 for TAL; +5 for plugins.

My take on this discussion.

I don’t have a problem with TAL at all, and in some ways it’s a really nice design.

I also don’t agree with the tone of this thread that TAL solved all templating issues 15 years ago and all template systems since have been mistakes.

I’ve learned that people think different ways and consequently look to different solutions. There’s nothing wrong with this and one of the fundamental tenets of Hugo has been the ability to use the solution you want. Hugo also follows the mentality that things should just work in the way you expect them to without pre-configuration and consequently provides sane defaults.

Going forward

If someone wants to integrate TAL into Hugo, I will 100% support that. The package mentioned above seems to be written by the original author of the TAL library so it is likely of good quality at least as far as implementing TAL as intended. The integration needs to be similar to how Amber and Ace are integrated as @bep mentioned above.

I also don’t think that TAL should be the default for Hugo ever. TAL is a fine approach, but there’s valid reasons why other templating languages have emerged and dominated since and we should respect that.

So for this to happen it would need:

  1. Someone to champion it
  2. Someone to add the integration, tests, docs, etc
  3. Someone to support it
1 Like

And since we have seen some examples of commit-and-run in Hugo, the third part is vital, but almost impossible to predict with new contributors.

I love to write code. I’m not a big fan of fixing and supporting others´ – when it’s of no use to myself.


New user perspective here: having more options in templating languages will be great! Especially the python templating languages like jinja2 are very welcome!

A plugin system that gives users free options to select whatever templating they like would be great - but currently I would be happy enough if there was only one templating language that would not generate newlines for every line of code instructions.

So Hugo compiled with Go 1.6 should do it.

yes, I have read this and will try it!

I know it might sound like heresy, but I would personally prefer one best way to do things as opposed to supporting many different systems. This is why as much as I like Jade I decided to go with standard Go templates. One could make a strong case that familiarity with Hugo implies a familiarity and even preference for Go and frankly learning Go templating is a stronger investment of mind share since it can also be used for creating templated microservices, sites and such with Go only.


I think PHPTAL is great and better for most uses than these other templating engines, but they have the advantage of being popular, for whatever reasons unknown to me. PHPTAL is still available for download and other implementations are too, but I don’t see them used in any CMS’s.

The syntax in Go templating is horrible, just like most others. If you take a close look at phptal you’ll notice it encourages proper separation of data and interface with no special coding required. Just add HTML attributes and ensure you have XHTML compliant pages and it all works.

I created an account here just to acknowledge the OP’s admiration of the little known TAL But I’m moving on to find another static CMS because Go doesn’t work for me.

@modparlor Interesting but odd starting post. Fortunately for us people like @spf13 don’t think something new is a waste of time.

There seem to be a few good reasons why TAL has not become popular. It doesn’t mean one is better than the other, just what appeals to more people.

From that example at, I was put off. Looks like a programming language intergrating a template, rather than the other way around. And I’m not keen on the idea of code within HTML tags.

Personally, I would like to see less code in templates. Something like limited to conditional logic, with the rest in linked and separated helper fuctions outside the template (so kind of further away from the TAL idea). This may be what mustache already is.

1 Like