TNTnet, just uploaded to Debian, looks interesting. Basically it offers JSP-/PHP-like embedding of C++ code into web pages (or the other way round). Well, if you want to be precise, the syntax is actually much closer to HTML::Mason, a perl-based web application framework I've used some years ago.

You can bet that these pages, compiled into native code, are hard to beat speed-wise... Think of compiling your website into your webserver.

It's obviously not suited for wide audiences - you can have your users upload PHP files, but you probably won't allow them to upload C++ code - but more for high-performance sites with specialized applications.

I have, however, one major gripe with it: The syntax is not XML.

I wish they would have picked true XML as data format, instead on basically using string processing. I hate how many people treat webpages as mere character strings with some special characters instead of structured data serialized in some way or another.

I don't want to be stuck using a line-based editor for structured data forever. I'm still using vim, and I'll probably continue for a while, but for XML I'm actually just waiting for an editor with a true understanding of XML and the power and speed-of-use of vim...

KID remains my favourite way of generating web pages. It's templating transparently embedded in a XHTML file using a separate XML namespace. And it's actually compiling the templates into python modules.

P.S. if your ever need the Dummy 16 and Dummy17 functions, get them from microsoft (excel) now! No need to write them yourself anymore! (Dummy 1-15 are apparently discontinued.)

P.P.S. I just wanted to point out, that I'm convinced that embedding much code into a layout file is a bad idea (one of the reasons why I despise PHP). Keep logics and layout separate. KID for example is quite good at that. In my DNSoupdate tool for example, all the template contains is loop constructs and simple case disinctions. This also brings me to my biggest gripe with KID: it depends on python. I don't see a way of using the same template with a different language. So maybe I'll actually go back to some TAL solution or so that is a bit more portable templating-wise (and still perfectly reuseable XML).