Hero – A handy, fast and powerful Go template engine
1–10 of 55 posts
Re: Hero – A handy, fast and powerful Go template engine
#2Is 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.
Re: Hero – A handy, fast and powerful Go template engine
#3Is 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.
It shouldn't be. I prefer template engines that I like the syntax and documentation the most.
For low traffic efficacy doesn't matter, for high traffic you should always cache the templates.
Re: Hero – A handy, fast and powerful Go template engine
#4I acknowledge the capability of the engine which seems rather impressive. But unfortunately it's basically obsolete.
How exactly are designers supposed to easily update? Why reinvent the wheel when far more matured templating engines exist?
As the web moves to the front end, this seems like a step backwards
Re: Hero – A handy, fast and powerful Go template engine
#5Template parsing doesnt need to be super duper fast. Most of the time you can cache the whole result.
I think its more important, to choose a good template language thats easy, and doesnt mix code with template content.
Re: Hero – A handy, fast and powerful Go template engine
#6Is 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.
It shouldn't be. I prefer template engines that I like the syntax and documentation the most. For low traffic efficacy doesn't matter, for high traffic you should always cache the templates.
Ideally, a template should be compiled into native code.
Re: Hero – A handy, fast and powerful Go template engine
#7Not escaping by default seems like a misfeature.
Re: Hero – A handy, fast and powerful Go template engine
#8I acknowledge the capability of the engine which seems rather impressive. But unfortunately it's basically obsolete. How exactly are designers supposed to easily update? Why reinvent the wheel when far more matured templating engines exist? As the web moves to the front end, this seems like a step backwards
>But unfortunately it's basically obsolete.
Not in any way that counts.
Re: Hero – A handy, fast and powerful Go template engine
#9Earlier quoted context omitted.
It shouldn't be. I prefer template engines that I like the syntax and documentation the most. For low traffic efficacy doesn't matter, for high traffic you should always cache the templates.
Ideally, a template should be compiled into native code.
Not necessarily.
1. that requires parsing the template at compile-time (making it non-overridable at runtime) or the ability to generate executable code at runtime which break in NX-mandatory environment (e.g. appstore applications)
2. the runtime version may be much faster than the compile-time one, e.g. the rust Regex crate has both a runtime Regex structure and a regex! compiler plugin, the latter is currently significantly slower at runtime: https://github.com/rust-lang/regex#usage-regex-compiler-plug...
Re: Hero – A handy, fast and powerful Go template engine
#10Not escaping by default seems like a misfeature.
According to the readme it seems to be escaping by default, kinda: So while the raw version is a bit too easy for my tastes (and the first to be listed) the escaped version is still easier/shorter than raw.