[ANN] Quicktemplate - fast, powerful and easy to use template engine

[Aliaksandr Valialkin]

Hi all,

If you:

- Afraid of using Go in web development due to insufficient html/template functionality?

- Avoid html/template, because it is slow?

Then use quicktemplate - fast, powerful and easy to use template engine. It has the following highlights:

- More than 20x times faster than html/template. See benchmark results.

- Powerful. Arbitrary Go code may be embedded into templates. I hope nobody will embed db or rpc calls :) Template functions deliberately omit error return type to make harder abusing 'embed arbitrary Go code' feature.

- Easy to use. Template syntax is clear. Unlike competing template engines, quicktemplate syntax contains minimal amount of implicit hard-to-understand and hard-to-use magic.

- Supports template inheritance via Go interfaces. IMHO, this approach is saner than 'template block' approach usually used in competing solutions.

- The majority of potential errors are detected either during templates' conversion to go code or during go code compilation.

- All the templates are compiled into a single application binary. This simplifies deployment - just copy a single binary to worker machines and restart it.

[Tyler Compton]

Hi Aliaksandr,

Thanks for sharing this. I remember with fasthttp you said that your improvements could not be added to net/http because of some fundamental design differences. Have you explored the possibility of rolling any of what you've discovered into http/template?

- Powerful. Arbitrary Go code may be embedded into templates. I hope nobody will embed db or rpc calls :) Template functions deliberately omit error return type to make harder abusing 'embed arbitrary Go code' feature.

I would definitely say this is more of an anti-feature. It's been shown that programmers can't handle that kind of responsibility, myself included. I would prefer to be forced to do the "right thing" even if it makes some tasks harder.

[Aliaksandr Valialkin]

On Tuesday, March 22, 2016 at 1:13:16 AM UTC+2, Tyler Compton wrote:

Hi Aliaksandr,

Thanks for sharing this. I remember with fasthttp you said that your improvements could not be added to net/http because of some fundamental design differences. Have you explored the possibility of rolling any of what you've discovered into http/template?

I believe html/template performance may be significantly improved, since currently it is very slow. The general optimization rule, which may be applied to any code, including html/template, is: write benchmarks, profile, use less reflection and re-use byte buffers.

But I have no desire to look into html/template performance, because I don't like html/template syntax :) Why learning yet another language for templates, which significantly diverges from Go syntax and has much more limits comparing to Go? It would be better to have a simple template language containing a couple tags for the most frequently used functionality, while other functionality (mostly various data transformations) could be easily implemented with arbitrary Go code embedded into templates.

Python has such a template engine - mako templates . Previously I took part in the prom.ua development - a big old e-commerce project with a lot of functionality and business logic. Thanks to mako templates, new UX features were developed very quickly and without significant problems (like spreading highly coupled transformation logic for a single specific template block among multiple places in the code because of template engine limitations). Many UX A/B tests were implemented only by modifying a couple of places in mako templates without touching the main logic.

When I switched to Go, I couldn't find decent mako-like template packages there. So when the need for such a package has been emerged, I re-invented the wheels and implemented quicktemplate, which works 20x faster than html/template as a nice bonus :)

- Powerful. Arbitrary Go code may be embedded into templates. I hope nobody will embed db or rpc calls :) Template functions deliberately omit error return type to make harder abusing 'embed arbitrary Go code' feature.

I would definitely say this is more of an anti-feature. It's been shown that programmers can't handle that kind of responsibility, myself included. I would prefer to be forced to do the "right thing" even if it makes some tasks harder.

YMMV. I don't like using tools which make me angry because of artificial limitations :)

--

Best Regards,

Aliaksandr