[eitland]

Last I checked Gos built in templating system lacked one feature that I see as very basic and that IMO makes it hard to organize code and templates logically:

To very common things to do when templating is

- to include a sub-template (e.g. the article template includes the sidebar template)

- to specify that the template I work with and probably others should be rendered inside a slot in a containing template (e.g. the article template should be rendered into the general root template that contains the public menu but the admin pages should render in another root template)

Last I checked only the first of these use cases were supported.

[ckdot2]

Both is possible. See here an example how to implement use case 2: https://github.com/ckilb/golang-layout-tpl-example

I don't like Go's template engine too much, I find it a bit cumbersome in many cases. But it's quite capable.

[ckdot2]

Here's a blog post which goes more into detail: https://kilb.tech/golang-templates

[shhsshs]

That is not quite a true "slot" behavior because the containing pages have to have a reference to the main layout via `{{ define "main" }}`

[ckdot2]

You're right. But this only means that it won't be possible that you use the same template for different slots. Personally, I don't remember I ever needed that. Actually, most template engines I know work this way (https://twig.symfony.com/doc/2.x/templates.html#template-inh..., "{% block content %}"). But still, it's easy to archieve that by just creating another sub template. So your first template file is the layout, the second one contains the main block definition, and that definition you just include another sub template which can be reused elsewhere.

[dgb23]

Doesn’t go template have a way to define functions? You could then use a function to do w/e you like.

[diceduckmonk]

That’s what I like about Go. The platform is prescriptive, but in all the right places. For things like this, Go leaves the abstraction building to you, if you need it.