pongo2 VS sprig

I've used https://github.com/flosch/pongo2 since it feels more dev friendly (like almost every other framework I've used). Check out https://github.com/avelino/awesome-go#template-engines for some others.

Doesn’t it bother your that your templates aren’t really valid HTML? Because of the way html/template works, one isn’t really able to implement template inheritance properly. So you end up with opening and closing tags scattered around multiple files? You might want to look at Pongo2, which implements most of Django’s templating syntax (incl. inheritance) and is pretty stable: https://github.com/flosch/pongo2

At least template-wise, I've developed pongo2 mimicking Django's template engine which I use myself for various projects. For the rest I usually stick with the standard library (net/http), golang-jwt, the Gorilla toolkit (note that it's been archived recently) and some software architecture patterns for middlewares, database abstraction, etc.

pongo2 is a community-built template engine with syntax inspired by Django-syntax. It is built by the community for Go. It is very popular today, with more than 2K stars on GitHub.

Django uses Jinja templating engine. Something similar is available at https://github.com/flosch/pongo2 Now you just have to pick which router you want and which ORM or not-ORM.

Yes, Go templating is quite hard. There was a feature request[1] to implement the Django/Jinja2-like Pongo2 template engine[2], but got rejected because it would have been a too big change.

[1]: https://github.com/gohugoio/hugo/issues/1359

[2]: https://github.com/flosch/pongo2

Yes, there is pongo2 [0] and my runner (basically a small Go software that runs the template engine) pongo2-runner [1].

I'm not the author of the library (pongo2), but I'm using pongo2-runner to dynamically create config files out of environment variables, with custom logic. Super recommended.

[0]: https://github.com/flosch/pongo2

[1]: https://github.com/swisscom/pongo2-runner

Standard Go templating seems really lacking if you come from something like Jinja. Even with libraries like https://masterminds.github.io/sprig/ (used e.g. for Helm templating) it feels hard to use.

Eleven, you'd be surprised what go template libs are out there like sprig. https://masterminds.github.io/sprig/

If you use Go templates be sure to use Sprig as well to get more usable functions.

I'd highly recommend tossing in the sprig library and depending on how you break up your templates, maybe creating a custom "include" helper instead of using the built in define/template helpers. The advantage of this is that if each template is capable of rendering itself independently, you can potentially render all of your templates in parallel.

The discoverability of golang templates is terrible, IMHO, since it's missing a "dir(locals())" equivalent and every execution environment gets to make its own rules about what pipelines/functions are exposed

Look at helm as an example: https://helm.sh/docs/chart_template_guide/function_list/ is some of them, https://helm.sh/docs/chart_template_guide/accessing_files/#p... are some others, but they also glued in some version of https://masterminds.github.io/sprig/ So, short of (a) knowing that's the case (b) having 3+ bookmarks in your favorite browser to refer to those reference pages, how would anyone know what pipelines are available?

Separately, I dooooo nooooooot understand why every joker has to invent their own new thing when we have like 50 or so templating languages already. Golang may be an outlier in that competition due to the Google Promotion Packet Effect(tm) but how they came up with `{{ range }}{{ end }}` as sane syntax is some true facepalm, to say nothing of the same landmine that ansible stepped on by not switching jinja2's default characters: `{{` is not _yaml safe_

You mentioned something about PHP. We also already have a templating language in the standard library that can be extended (commonly done with sprig).

Plopjs looks interesting and is probably not too hard to write for yourself in Go. You could add something like sprig for some useful template functions.

Not at all. It was "write a helm template using the following imaginary values in a values file". In 30 minutes, I was able to google the Kubernetes api and the sprig functions for templating, complete the assignment, fix a stupid typo the unit test caught, and spend 5 minutes trying to think of any corner cases that hidden unit tests might catch (I don't know if there were any hidden unit tests). The goal of this take-home assessment was to prove that you are not wasting an engineer's time when they call you, not to prove that you should be hired.

Support sprig in Template

They may refer to the definitive shortage of built-in functions. The template engine itself only provides the bare minimum. That's usually not a problem because of template function libraries like https://github.com/Masterminds/sprig