Pongo2 – A Django syntax-like template-engine for Golang | Hacker News Reader

Pongo2 – A Django syntax-like template-engine for Golang

florian-schlachter.de

38 pointsflosch11 comments

I love the Django-style syntax for HTML templates, but if I'm working on something on the web and I'm using Go it's probably for speed reasons. This means that I'm probably trying to avoid reflection. There's a bit of competition going on between HTML template libraries for Go and I'm not sure any has truly satisfied the majority of use cases. I'm curious to hear what other libraries people are regularly using.

The std. lib's html/template still uses reflection.

I love django/jinja and I hope it gets standardized as the default templating syntax for all languages.

I've been following pongo since day one and this release makes me really happy.

Don't ask me why but I hate go/template to death.

I remember some years ago, I needed to quickly prototype a proof of concept php project, and the first thing I did was find a django templating library for php; simply because I was lazy to learn back Smarty's syntax.

It's interesting, I feel that if the trend of jinja-likes continues, we will eventually end up with another abstraction layer on top of the templating system; eg. a templating system that "compiles" to whatever you're using right now.

One alternative being a single unified "jinja" syntax with several backends.

In any case, good job on this! It looks really good.

So, this isn't Jinja2? I thought Django was using Jinja2, but I guess I was wrong.

Jinja is a bit more liberal when it comes to bringing pythonic syntax to the template, while Django retains a philosophy of "designers are sheep and we must feed them grass".

Disclaimer: I think part of that previous statement might be biased.

To rephrase it more charitably - Django's philosophy might be better summed up as "if you need a full programming language in your templates then you're doing something wrong".

Remember PHP started as a templating language and look where that got us.

Heh. Don't get me wrong, I agree with the general philosophy, but they took it a bit far. Before Django 1.3(?), there was no {% if x == y %}, or != etc; instead you had to use {% ifequal %}, {% ifnotequal %} and so on. Pretty ridiculous.

There are some similar lingering design decisions which do nothing but make the language uglier and more verbose. Jinja has the same philosophy of not doing evals in the template, but is still quite a bit more pythonic (eg. method calls with arguments, most python objects etc are allowed)

I'm curious to see when those things actually result in better code. A template tag is usually a much better idea and hardly onerous in terms of time or code.

Django's opinionated stance on this helped me to become a better developer. It pushed that stuff back into my views - which in turn made me realise that a lot of the stuff I'd been putting in my views really should be pushed back into a layer below that. It set me on the path to understanding the value of a good separation of concerns.

Thanks!

Reply on news.ycombinator.com