Live data from Hacker News

Hero – A handy, fast and powerful Go template engine

github.com

51–55 of 55 posts

Re: Hero – A handy, fast and powerful Go template engine

#51
post #39

Adding a whole dependency to shave a few milliseconds off serve times (at most) seems like a bad deal to me. All the usual bad stuff that comes with dependencies: will it be maintained? Will it have breaking changes? Will it leftpad? And everyone knows the standard library template format, all the editors support it, if another coder joins the team they'll know it. Meh, maybe I'm just not the target market for this..…

I've been looking for a good template engine that supports compilation, but the goal is not speed. Although you can rely on testing, I'd like to get type-checking for templates at compile time.

In my experience with Go, sticking with the stdlib as much as possible is always the best option.

I'd add whatever functionality you need to html/template in your own code rather than import a dependency.

Re: Hero – A handy, fast and powerful Go template engine

#52

Earlier quoted context omitted.

These are not even milliseconds, the charts are in microseconds and a reduction of 40 to I agree it's not worth the focus on fast, they should be focussed on improving the API for the stdlib templates (for example loading templates is not obvious, what I'd like to do is point it at a directory and load all templates under that dir, being able to set layouts and partials would be nice etc). Speed is not a big problem…

> what I'd like to do is point it at a directory and load all templates under that dir Doesn't https://golang.org/pkg/html/template/#ParseGlob do exactly that?

Not really because there are several limitations, e.g. you can't have multiple templates with the same name, I like to key them by path and have several index templates for example.

Re: Hero – A handy, fast and powerful Go template engine

#53
post #49
post #46

Earlier quoted context omitted.

I don't like Go Templates. My issue is that you can't have small calculations easily. You'd have to add a lot of helper functions or prepare everything before passing to template engine. Now there is too much coupling. And not that fun. This one allowing inline Go code solves that issue. Disclaimer: I wrote a template engine ( https://github.com/eknkc/amber ) to make this easier (and I like that Jade syntax)

I always considered the actual template to be the presentation layer relative to the templating context. Having worked on large scale applications it has become apparent to me that performing business logic in the presentation is not the way to go. In my opinion, a templating application should be architectured in such way that your data is transformed to exactly how you want it to be presented prior to it getting to…

While I agree in theory, I can't stand that in practice :).

For example, let's say I want to show a usage stat, I'd pass something like { usage: 100, limit: 1000 } to the template engine. Let's say I want to add a percentage. I believe the calculation should be on the presentation layer. That's how I decide to present this particular data.

Go templates lack that functionality for no good reason. And if I'm gonna calculate that on the backend, why exactly am I using a template engine? I'd concatenate strings.

Re: Hero – A handy, fast and powerful Go template engine

#54
post #53
post #49

Earlier quoted context omitted.

I always considered the actual template to be the presentation layer relative to the templating context. Having worked on large scale applications it has become apparent to me that performing business logic in the presentation is not the way to go. In my opinion, a templating application should be architectured in such way that your data is transformed to exactly how you want it to be presented prior to it getting to…

While I agree in theory, I can't stand that in practice :). For example, let's say I want to show a usage stat, I'd pass something like { usage: 100, limit: 1000 } to the template engine. Let's say I want to add a percentage. I believe the calculation should be on the presentation layer. That's how I decide to present this particular data. Go templates lack that functionality for no good reason. And if I'm gonna calc…

Actually you can do function calls on Go templates [1], and indeed this is what is done in practice. Libraries got written to do this, and badly integrated [2].

You will quickly find if you use this that it's in fact worse: go templates have LISP syntax. A set of atoms, specified in reverse Polish notation, doing function application to all but the first atom.

[1] https://golang.org/pkg/text/template/#Template.Funcs

[2] https://github.com/Masterminds/sprig

Re: Hero – A handy, fast and powerful Go template engine

#55
post #53

Earlier quoted context omitted.

While I agree in theory, I can't stand that in practice :). For example, let's say I want to show a usage stat, I'd pass something like { usage: 100, limit: 1000 } to the template engine. Let's say I want to add a percentage. I believe the calculation should be on the presentation layer. That's how I decide to present this particular data. Go templates lack that functionality for no good reason. And if I'm gonna calc…

Actually you can do function calls on Go templates [1], and indeed this is what is done in practice. Libraries got written to do this, and badly integrated [2]. You will quickly find if you use this that it's in fact worse: go templates have LISP syntax. A set of atoms, specified in reverse Polish notation, doing function application to all but the first atom. [1] https://golang.org/pkg/text/template/#Template.Funcs…

Yeah this is the reason I went ahead and wrote the template engine I mentioned in the parent comment. It compiles down to go templates. I inject generic math functions [1] and convert an expression like 4 + 5 * 3 to go template function calls. It's ugly but the compiler generates it so whatever :)

[1] https://github.com/eknkc/amber/blob/master/runtime.go

Post reply on HN