<DISCLAIMER> I have never written a templating engine. Anything posted here by someone who has probably takes precedence over what I say here. </DISCLAIMER>

A thing can only be fast relative to another thing. If ego were the only templating solution available to software developers it would be meaningless to describe it as "fast". I have never used ego and do not know how much faster it is than the alternatives (if at all).

However, ego templates are compiled to go source which ends up as machine code in your program that just writes out the strings. I believe most alternative templating libraries parse your template into a data structure at run time and then need to walk that data structure every time you want to render the template in a new context.

So, consider a template like "<div> <h1> {{title}} </h1> <p> {{description}} </p> </div>"

Using the ego strategy the code that has to execute to render it amounts more or less to a linear series of 5 calls to a method that appends strings into a buffer.

Using an interpreted-template strategy, i don't know exactly what that machine code is going to look like but it necessarily involves a lot of consulting the parsed template to see what the next step is, and maybe even a lot of lookups of strings in hash tables.

Aside: In the Java world, the fastest template rendering engines probably compile a template into JVM bytecode which can then be loaded and executed in the current process, yielding what could reasonably be considered the best of both worlds.

I guess it's because the templates don't have to ever be parsed since they're transpiled to Go code at compile-time. It's been a while since I've used Go's template packages but I thought that they're only parsed once no matter how many times you execute it (assuming reuse of the Template struct). So to me, it seems there should really be no difference from just putting the initialization of the template in an init() func.

Ego is as fast as it gets for tenplating, as it compiles the template to Go code. It probably doesn't matter that much performance wise in this case, I would've used it either way.