Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Hero – A handy, fast and powerful Go template engine

github.com

Post reply on HN
Print view View original

41–50 of 55 posts

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

#41

Post by icholy »

Zach_the_Lizard wrote: post #29
camus2 wrote: post #19

Earlier quoted context omitted.

Go template language has a nice context sensitive escape mechanism. But the syntax is kind of garbage and it's very limited when it comes to features ( no template inheritance, curb-some API for plugins ... ). Like everything in Go it gets you 50% there and but it's PITA to do something complex with it. Go is really bait+switch . You can get started fast but then you run into a vast amount of issues when it's time to…

Can't help but agree. I write Go professionally now and it's just not a productive language. The concepts are there, but the execution was frankly quite lazy and inconsistent. Never panic in an external API, but closing closed channels and random number functions panic in the same way Java throws checked exceptions. Generics aren't important, except for slices, maps, and channels which are generic. Really minor thing…

When a program panics, it's saying that there is a fundamental problem with your logic. Closing closed channels and dividing by zero are both examples of those.

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

#44

Post by thewhitetulip »

asitdhal wrote: post #2

Is template parsing a major bottleneck ? What I know, most web apps need template parsing only at the beginning. Once initial startup is done, delivery of content is mostly constant.

If you are using a front end framework, even this is not an issue.

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

#45

Post by davexunit »

Another day, another string-based template engine that will lead to invalid output and injection attacks. You don't need a new language specifically for templates, you need to use a real programming language with real data structures that represent the HTML/XML nodes.

http://www.more-magic.net/posts/structurally-fixing-injectio...

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

#46

Post by eknkc »

ktzar wrote: post #38

I've seen a few articles from Golang users saying that, after trying to fight the standard library in many ways, they just end up using it since they realise it's the best balance between usable and extensible. Taking how great the Golang templating engine is, I'm not sure this is a step forward.

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)

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

#47

Post by mi100hael »

thewhitetulip wrote: post #44
asitdhal wrote: post #2

Is template parsing a major bottleneck ? What I know, most web apps need template parsing only at the beginning. Once initial startup is done, delivery of content is mostly constant.

If you are using a front end framework, even this is not an issue.

Only because you've offloaded half your CPU load to your user's cell phone.

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

#48

Post by majewsky »

lime66 wrote: post #18
majewsky wrote: post #13

The benchmarks in the README show a whole lot of templating engines, but weirdly omit the standard library module: https://golang.org/pkg/text/template That's more than enough to raise my eyebrow.

"Golang" is the standard library. And the code is here https://github.com/SlinSo/goTemplateBenchmark/tree/master/go .

Huh, how could I miss this? (Maybe because the "G" looks too much like "C", so I scanned "Co..." and skipped that entry.)

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

#49

Post by sepbot »

eknkc wrote: post #46
ktzar wrote: post #38

I've seen a few articles from Golang users saying that, after trying to fight the standard library in many ways, they just end up using it since they realise it's the best balance between usable and extensible. Taking how great the Golang templating engine is, I'm not sure this is a step forward.

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 the presentation layer. Up in presentation, you should really only have to worry about checking if a condition is true or false or iterating a collection. From what I have seen of Golang, some (not all) design decisions seem to have been made to make it difficult to make such mistakes easily, so I would not be surprised if making it difficult to do logic in the template was a conscious decision.

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

#50

Post by marcus_holmes »

grey-area wrote: post #17
marcus_holmes wrote: post #12

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..…

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?

Post reply on HN