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

<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.