@hhariri The main problem for my team is the long compile times. Maybe kotlinx.html should not have been used to implement all our templates with, because it more than doubled our compile times (while it is only 35% CLOC of our code base). I've raised an issue on Github, and added to the discussion several issue on YouTrack (all linked from the issue on Github). As you can read in the GH issue I've used @spand’s example code to create a benchmark and found some ways to improve the compile time issue significantly (still not fast, but double digit percent improvements). I've created a hacked version of kotlinx.html with some exception handling removed, that we currently use internally and on production which improves compile times somewhat. But so far I did not see any involvement of kotlinx.html maintainers on this topic. Why is there exception handling in there while (1) it works without, and (2) it slows down compilation considerably (see benchmark results). I understand kotlinx.html is free and I really feel grateful for it. I really like the eDSL approach to HTML templates. I dont want to be "just nagging", and I want to give back, so I publish all my findings and benchmark code. I do think a little warning on kotlinx.html's project page telling potential users that it can significantly increase compile times would be nice (I would like to have known). Also I'm really curious why the exception handling is in there given that --in our case-- it works so well without.

I’ve pinged my colleague to take a look into this and see what we can do. It will be a few weeks though as he’s currently away. Sorry for the delay.

No worries about the delay! Thanks for looking into it, much appreciated. I'll see if I can run a benchmark with some inline statement(s) removed as @peekandpoke suggested.