Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

In addition to a emulating certain teachers dogged insistence of making sure students can't have nice things (an absolute no-brainer feature like generics only showed up recently...!), last time I tried to use Go for a web project a few years ago I was also amused by the lack of templating libraries - the way to make pages was to string together header + main + footer, the old PHP way...! Not a single library supported template composition.


Umm... what are you even talking about?

Go has had templating built into the standard library since... forever?

And Go templates can use other templates, as long as they're all loaded into the same context, if that's what you were getting at.

simple examples of Go's built-in templates: https://gowebexamples.com/templates/

templates using other templates: https://levelup.gitconnected.com/using-go-templates-for-effe...


I've found Go's templating to be pretty great


That doesn't look too bad on a quick glance, but the possibility to say that "this content goes in that template" still seems to be missing.

Look at this page: https://quarkus.io/guides/qute-reference

and read about “Template inheritance” in 3.5.6 to see what I mean.


In this example, I'm passing an object with a single value into the header template, but it could have as many values in it as needed: https://go.dev/play/p/kC8pm4Z4WrH

Go doesn't really do template inheritance in the way I think you're meaning. Go prefers composition over inheritance, and that carries over to the templating system. Go templates let you pass a parameter to the template you're calling, which I believe addresses the need you linked to. Calling another template is not just simple string concatenation; the other template can act on input provided by the calling template.

There are a lot of different ways to approach templating pages in a web app. I think Go's templating system is one of the least objectionable ones I've used.

I have no experience with Quarkus, so I can't say how good or bad that one is, but my experience with Ruby templating systems is that people often start mixing complex logic into the templates, including database calls, and that causes things to get messy. Go's template environment is very minimal by default, and you can extend it with custom functions if you want to give more power to the templates, but Go encourages you to compute your data ahead of time, then pass it into the template... and just have your template be a template for formatting the data.


> people often start mixing complex logic into the templates, including database calls

Sometimes you can solve social problems with technical interventions, but at this point, someone needs to sit down and talk :-)

> Go encourages you to compute your data ahead of time, then pass it into the template

Same elsewhere including modern PHP and Java.

The thing that is missing in Go is a natural way to group together what goes around the content.

Sure, stringing together the templates (yes, I know the other template can act on input provided by the calling template, but they are still stringed together) feels weird when what one really wants is to fill in slots in a design, which is my thought process.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: