31–40 of 55 posts
It's unfortunate the post title was "fastest go template engine" since that draws away from how different the API is from the standard lib (think ERB/EJS v Mustache).
While I'm personally in the "logicless" camp, I know a lot of people who'd appreciate this. Even I would when building something quick and dirty.
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…
:P
Earlier quoted context omitted.
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.
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…
Google will probably fix these things with time though, or so I hope - at the moment go seems like a conflicted language.
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..…
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.