No, i am not kidding at all, but i may very well be blind. Then again, you just admitted to having to use Zope ... no wonder you have such a bad impression of HTML templating. ;)

However, i finally understand what you are arguing against. Perl grabs HTML which contains more Perl. But you know what? I don't think that is bad at all. In fact, i think it is wonderful! You seem to be more concerned with premature optimization than maintainability and readability. Yes, your way executes faster ... but does it even matter? Remember, the Internet is a Von Neumann Bottleneck. Who cares if your templates generate 5 seconds faster than mine if it takes 15 seconds to send them across the wire. And more imporantly, who cares if your templates generate faster than mine if it takes the HTML developer longer to understand how to even make changes, much less where to find what needs to be changed.

Besides, are tags like <tmpl_var>, <tmpl_if>, <tmpl_loop>, and <tmpl_include> really "code"? Well yes, but it is a very slimmed down code, now, isn't it? This isn't very much for an HTML designer to have to understand. Now, granted that Template Toolkit is much more complex and does allow for full out Perl code ... but i don't use it with a team. (And besides, Template Toolkit is FUN man! Don't you like to have fun coding?!?)

Listen. If it's just you or me that's handling the whole darned web site (coding and design) ... then pick whatever floats your boat. But if you are working with a team of HTML developers, i garuantee you that they will be more comfortable with:

<table>
<TMPL_LOOP data>
<tr>
   <td><TMPL_VAR foo></td>
   <td><TMPL_VAR bar></td>
   <td><TMPL_VAR baz></td>
   <td><TMPL_VAR foo></td>
</tr>
</TMPL_LOOP>
</table>
[download]

Um ... how the heck do you even do that with Text::Vpp?!? Nowhere in the docs is mention of how to use a FOREACH loop. Instead you have to delve through the undocumented test scripts and nowhere is an example of looping through a list of hashes. Also, nowhere is there a mention of using Text::Vpp to drive dynamic websites. This is really starting to look like the wrong tool for the job ... (and get this, the module hasn't even been updated in the past 2 years!)

Even the docs for Text::Vpp warn you against adding complexity to your code:

Adding Vpp syntax in your code will make it more
difficult to maintain. Even more so if the code maintainer
will not be yourself. Furthermore, the build procedure may
also be more complex. So please, do consider the trade-
off between speed and complexity.

Sure, the context is about using Text::Vpp to pre-process your code to gain speed, but again ... nothing about using Text::Vpp to drive dynamic websites. Now i start to really believe that this is not the right tool for the job. Please stop making me waste time on this pointless, pointless, pointless argument.

L-LL-L--L-LL-L--L-LL-L--
-R--R-RR-R--R-RR-R--R-RR
B--B--B--B--B--B--B--B--
H---H---H---H---H---H---
(the triplet paradiddle with high-hat)

A tip.

If your website has decent volume and you are using mod_perl with lots of dynamic content (hopefully with templating), then you probably want to be using a reverse proxy setup. See this guide (particularly Adding a Proxy Server in http Accelerator Mode) for an explanation of what it is and what the benefits are. From your point of view the big benefit is that a mod_perl server ties up a lot of memory, so that configuration allows you to have fewer big mod_perl processes all actively producing content, and let the proxies take care of returning data over the slow wire to the browser.

After you do that then the answer to your rhetorical question about why it matters how fast the mod_perl executes is that improving speed there will reduce how many heavy mod_perl children you need for a given load, which will save on memory and CPU requirements (which translates into the number of webservers that you need).

Another detail. What I (and many other people) dislike about Zope has nothing to do with templating. In fact I dislike the same thing about the way that this website is designed and the way that many Smalltalk and/or Lisp projects are run. And that failing is that Zope wants to store an opaque binary image (in its case in an object database) that includes HTML and code. That immediately takes the wonderful world of filesystem-based tools (everything from grep to revision control tools) and throws them out the window. Work its way and you have to reimplement all of them, and learn the new toolset just for Zope. And if it gets them wrong, then enjoy trying to manage your releases (eg roll code forward and back).

This design decision is completely orthogonal to whether or not to use templating, and it seems that you missed it.

I won't comment on your other points since I mostly agree with you.

If your website has decent volume and you are using mod_perl with lots of dynamic content (hopefully with templating), then you probably want to be using a reverse proxy setup.

Let me second (or third or fourth?) that thought.

I'm using a reverse proxy cache for stonehenge.com, and the flexibility it offers is amazing and amazingly practical.

I also helped a large university do that, and their response time during heavy load went from 30 seconds to 2.5 seconds on one particular critical application.

It's a useful technique, even if you have only one machine, because it's still a net win, especially if you ever deliver to clients on slow networks.

I wrote about setting up a split-server arrangement in one of my columns.

-- Randal L. Schwartz, Perl hacker
Be sure to read my standard disclaimer if this is a reply.