I haven’t found many discussions online – in any sort of depth – about the quicktemplates package. While it’s interesting that it generates raw Go code and provides impressive speed improvements, a few things make me nervous about it. I was hoping to get others’ thoughts before making my decision on whether I’ll use it or not.
A few of my concerns:
It seems like a very “PHP-like” way of writing templates. I’m not sure how else to describe it
While faster, how much of an issue is speed really in the html/template package really? I haven’t seen any issues
It exposes a lot of pure logic to the view and this seems to push/allow the view to handle more logic than you typically want. Even some examples I saw of it in use seemed to be doing too much in the view whereas in a typical Go application they would have been handled by the model or controller layers. I am not positive, but I’m quite sure you could query the DB right from the view as it allows full functions to be written in it.
The stdlib mostly just gets passed objects and allows a few if/else statements within the template itself. quicktemplate seems to be all about writing pure Go functions within the views.
I don’t mean to bash the package at all. I’m considering it after all. And while it doesn’t require you to do some of the things listed above, it certainly doesn’t seem as safe nor prevent others from pulling a bonehead move.
Has anyone used it? Any major pros? Am I way off base here?
In my experience speed isn’t a big issue with the stdlib templates - I haven’t measured specifically but I’d be surprised if they add more than 1-2ms to rendering at most (slowest bench in the stdlib BenchmarkTemplateSpecialTags is .2ms/op here). 20x faster than 0.123392ms in their benchmarks is not very important. I really think it’s a mistake the Go benchmarks are in ns, it makes it harder to reason about whether the results are in any way important, because once you’re down under 0.5ms per request say, speed ups are not so important, but I guess they use ns as they also benchmark tiny operations like string concat etc which might be repeated lots. Important to compare the times with all the other work you’re doing though and optimise for stuff which takes a long time in your server.
The default templates also have nice contextual escaping - that is very important, looks like this one you linked requires you to escape manually for different situations, I’m not so keen on that but it is explicit I guess.
You can write functions in the stdlib templates, you could in theory do all sorts of crazy stuff there too, so this is more a matter of discipline and style I feel, I agree better to keep logic limited within templates.
My biggest objection to another templating language would simply be the almost unintentional lock-in choosing an esoteric templating language causes - it’s a huge job to redo all your templates, and get others up to speed on your choice if you collaborate, and it’s painful if the community starts to use lots of different template libraries as apps would be harder to decipher.
It looks like an interesting project to look at though, worth looking at even if you don’t use it.
@kennygrant Appreciate the feedback. Good to have another set of eyes on it. You bring up some really good points. Showing the time in ns makes the brain think the difference is larger than it really is. Not something I considered.
It seems you’re right that; you can do crazy stuff in the stdlib template. I guess it just doesn’t encourage it so much which leads to me forgetting that there is even that ability.
I definitely don’t think it is uninteresting. I just think that the benefits it lauds are not ones that outweigh the drawbacks for me. I’ll keep an eye on it for sure though.
I think I prefer that approach as it sticks with he same semantics, so in theory you could swap it in and out easily, but then it does limit the authors to all the design decisions taken in the built-in templates.
It is no surprise you can get a speedup with code generation.
Hugo uses lots of (standard) Go templates, and code generation is not an option. With rendering speed at < 1ms per page we’re doing well, and that includes all processing, not just templating. Looking at the profiler, the template package is a big part of it, but the flexibility comes at a cost, I guess.