11–20 of 55 posts
Earlier 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.
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...
That's more than enough to raise my eyebrow.
I 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
Many web sites are perfectly fine with pure HTML/CSS.
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.
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.
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.
The problem with Golang, most developers look for performance instead of the features. People who use python or ruby look for better features and ease of development. So, Golang engineers develop applications and libraries which doesn't help anyone.
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..…
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.
Earlier 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.
Exactly, I used django and jinja templates. Those two are feature rich. Golang template engine is mostly minimal with enough feature to do things. The problem with Golang, most developers look for performance instead of the features. People who use python or ruby look for better features and ease of development. So, Golang engineers develop applications and libraries which doesn't help anyone.
Not escaping by default seems like a misfeature.