There are a lot of good reasons to use H::T over TT:

• TT is too heavy for what you want.
• Excel::Template and PDF::Template are UI-compatible with H::T
• H::T is preferred in some systems, such as CGI::Application

Now, TT is more featureful and has its own UI-compatible friends, like Jemplate. It all depends on what your needs are.

TT is too heavy for what you want

Sorry - this is long...

I hear the "too heavy" argument a lot as a reason to not use TT. I've provided a test script below with benchmarks that show relative speed for a highly contrived template. If TT is used in a mod_perl environment - it is faster than HT. In a non-mod_perl environment (or also in a mod_perl environment you could always use CGI::Ex::Template and then you have the full features of TT with the "lightness" of HTML::Template.

The other reason I hear is because they don't want to give too much ability to the HTML designers or because they don't want to have business logic in the templates. The first point seems roughly equivalent to SysAdmins on my network telling me I have to use Lua because they don't want me to have too many features in my programming. On the second point - there is almost nothing you can do to prevent your designers from controlling business logic from the HTML -- Javascript provides all the rope they need to hang themselves. The only option here is to ask them not to do that.

So if all the points for using H::T are really veiled non-issues - then the only real reason to pick H::T over TT or likewise to pick TT over H::T is one of religion and is generally based on what system the developer started with in the first place.

Well - anyway - the following is a script that tests the templates under different operational modes - passing in a string containing the template, passing in a file containing the template, and caching the template in memory, or the compiled template on the file system (isn't it funny that they all have essentially the same feature sets but have diffent APIs and syntax). This file is included with the CGI::Ex suite under the samples/benchmark directory. Unfortunately the copy of this file on cpan is out of date - but will include this updated file in the next release.


Read more... (12 kB)


That script output the output below on my machine (I've removed some of the timethese output to shorten what is presented). Remember that the template is used for the test is trivially short - but it does give a good approximation of "heavy" vs "light". The following abreviations are used:


TT  - Template Toolkit with non-XS stash
TTX - Template Toolkit with XS stash
HTE - HTML::Template::Expr
HT  - HTML::Template
CET - CGI::Ex::Template

_str     - Means the module was passed a string containing the templat
+e.
_compile - Means the template was cached on the file system.
_mem     - Means the template was cached in memory.


----------------------------------------------------------------------
+--
From a string or scalarref tests
               Rate    TT_str   TTX_str  HTE_str    HT_str  CET_str Te
+xtTemplate
TT_str        273/s        --       -8%     -72%      -80%     -82%   
+      -83%
TTX_str       296/s        9%        --     -69%      -78%     -80%   
+      -82%
HTE_str       961/s      252%      224%       --      -29%     -36%   
+      -40%
HT_str       1346/s      393%      354%      40%        --     -10%   
+      -16%
CET_str      1499/s      449%      406%      56%       11%       --   
+       -7%
TextTemplate 1605/s      488%      442%      67%       19%       7%   
+        --
----------------------------------------------------------------------
+--
Compiled and cached on the file system tests
              Rate  TT_compile TTX_compile  HT_compile CET_compile
TT_compile   694/s          --        -11%        -62%        -71%
TTX_compile  775/s         12%          --        -57%        -67%
HT_compile  1817/s        162%        134%          --        -23%
CET_compile 2353/s        239%        204%         30%          --
----------------------------------------------------------------------
+--
Cached in memory tests
          Rate HTE_mem  TT_mem  HT_mem TTX_mem CET_mem
HTE_mem 1374/s      --    -37%    -41%    -57%    -60%
TT_mem  2167/s     58%      --     -7%    -31%    -38%
HT_mem  2340/s     70%      8%      --    -26%    -33%
TTX_mem 3163/s    130%     46%     35%      --     -9%
CET_mem 3474/s    153%     60%     48%     10%      --
----------------------------------------------------------------------
+--
All variants together
               Rate TT_str TTX_str TT_compile TTX_compile HTE_str HT_s
+tr HTE_mem CET_str TextTemplate HT_compile TT_mem CET_compile HT_mem 
+TTX_mem CET_mem
TT_str        285/s     --     -0%       -59%        -64%    -68%   -7
+9%    -79%    -80%         -83%       -84%   -87%        -88%   -89% 
+   -90%    -92%
TTX_str       286/s     0%      --       -59%        -63%    -68%   -7
+9%    -79%    -80%         -83%       -84%   -87%        -88%   -88% 
+   -90%    -92%
TT_compile    692/s   143%    142%         --        -11%    -23%   -4
+9%    -49%    -51%         -59%       -62%   -68%        -70%   -72% 
+   -76%    -81%
TTX_compile   782/s   175%    174%        13%          --    -13%   -4
+2%    -43%    -45%         -54%       -57%   -64%        -67%   -68% 
+   -73%    -78%
HTE_str       903/s   217%    216%        30%         15%      --   -3
+3%    -34%    -36%         -47%       -50%   -59%        -62%   -64% 
+   -69%    -75%
HT_str       1346/s   373%    371%        94%         72%     49%     
+--     -1%     -5%         -21%       -26%   -38%        -43%   -46% 
+   -54%    -63%
HTE_mem      1360/s   378%    376%        96%         74%     51%     
+1%      --     -3%         -20%       -25%   -38%        -42%   -45% 
+   -54%    -62%
CET_str      1409/s   395%    393%       104%         80%     56%     
+5%      4%      --         -17%       -22%   -35%        -40%   -43% 
+   -52%    -61%
TextTemplate 1697/s   496%    494%       145%        117%     88%    2
+6%     25%     20%           --        -7%   -22%        -28%   -32% 
+   -42%    -53%
HT_compile   1816/s   538%    536%       162%        132%    101%    3
+5%     34%     29%           7%         --   -17%        -23%   -27% 
+   -38%    -50%
TT_mem       2177/s   665%    662%       214%        178%    141%    6
+2%     60%     54%          28%        20%     --         -7%   -12% 
+   -26%    -40%
CET_compile  2346/s   724%    721%       239%        200%    160%    7
+4%     72%     66%          38%        29%     8%          --    -5% 
+   -20%    -35%
HT_mem       2477/s   770%    767%       258%        217%    174%    8
+4%     82%     76%          46%        36%    14%          6%     -- 
+   -16%    -32%
TTX_mem      2943/s   934%    930%       325%        276%    226%   11
+9%    116%    109%          73%        62%    35%         25%    19% 
+     --    -19%
CET_mem      3617/s  1171%   1166%       423%        363%    301%   16
+9%    166%    157%         113%        99%    66%         54%    46% 
+    23%      --
[download]



So using Template Toolkit with the XS stash in a mod_perl environment would offer the best performance (not counting CGI::Ex::Template in a cached environment). I do agree that using TT in a CGI environment without any caching may be a bit heavy (I use CGI::Ex::Template in those cases). This has been a long answer to a short comment about TT being too heavy. Apache is heavy too - but it gets the job done.

Personally I use whatever templating system the previous coder used when I go in and maintain code. But on all new work I use CGI::Ex::Template because it gives me the power of TT, but is even faster and lighter.


my @a=qw(random brilliant braindead); print $a[rand(@a)];

Dude, where's HTML::Template::JIT? I guess you didn't want to blow your premise by including the fastest templating system known to man. (I kid - honestly there's a good reason no one uses it, and that's because templating is almost never the bottleneck!)

-sam

Using TT from CGI::Application is rather straightforward by means of either CGI::Application::Plugin::TT (which I happily use) or CGI::Application::Plugin::AnyTemplate (which I never used, but I suspect it's easy as well).

Flavio
perl -ple'$_=reverse' <<<ti.xittelop@oivalf

Don't fool yourself.

Well, there really isn't a reason this would start a flame war, T::T is a more powerful library. You have plugins from all sorts of modules, like DBI, CGI, Data::FormValidator, the list goes on. Check out the docs for a more robust list.

Out of the two, I'd choose Template::Toolkit. But that's only because I've used both, and found that it provides more of what I need at this point in time. You can do a lot with HTML::Template, it's a really simple and neat little module, but it's hard some times to deal with when you're manipulating large and complex data structures. It would be a good starting point though.

Have you looked at HTML::Mason as well? It's a little more like PHP in the sense that you can embed your perl code right into your template, but you can also abstract all your mark up away into "elements" as Mason calls them. Pretty neat if you have mod_perl and some time to install it.

Hope this helps!

• Default syntax stands out from HTML (however, I believe you can change the default HTML::Template syntax if you want.)
• You can call methods on objects passed to your templates. Some people abhor this, but I like to do it for Class::DBI and DateTime objects.
• TT has built in methods for iterating over hashes and arrays, whereas with HT you have to coerce things into an AoH to iterate. TT even allows recursion.
• It's easy to install new VMethods in TT for doing things to arrays and hashes (and scalars.) This can be a real time-saver if you don't want to do these things in your Perl code.
• TT has a lot of plugins available, for handling everything from LaTeX to DOM stuff within your templates.
• You can embed Perl in your templates. This has never seemed like a good idea to me, but it's there if you want it.

1. Programmers, who will be tempted to abuse TT's power, and end up putting business logic in the templates (I count myself in this camp: the temptation is strong)
2. Non-programmers; mostly graphic designers and/or end-users with administrative privileges, who don't know enough about programming to understand TT. H::T is simple enough for them to grok, but more complexity would be too overwhelming

Hm... possibly you should consider using Mason then... one of Mason's strengths is that Mason templates tend to have the feel of HTML, which lets web-designer types feel like they know what's going on. Hypothetically a perl programmer might be inclined to slip in a lot of perl into the template, but in practice it's just as easy to put it in a perl module, and just add just enough glue code into the template to get it to use the module.

Myself, I'm less familiar with Template Toolkit, but I would say if you have a choice of ways to do it, you probably want to use either Mason or Template Toolkit: those are the two competing schools at the moment (notably they both have O'Reilley books), and in effect they're defacto standards.

Choosing a Templating System

I'm going to jump onto the Template::Toolkit bandwagon. The main package for my most recent web application, called File Exchange System, looks like this:

[...]

use base CGI::Application;

use CGI::Application::Plugin::Session;
use CGI::Application::Plugin::TT;
use CGI::Application::Plugin::Stream qw/stream_file/;
use CGI::Application::Plugin::DBH qw/dbh dbh_config/;

use Template;

[..]
[download]

That gives my CGI::Application application session handling, templating, streaming (for stable file downloads) and intelligent database handle handling.

In addition to using Template Toolkit for web applications, I also use it for the installation script -- I have configuration file templates (for startup.pl, httpd.conf, Log::Log4perl files, and a main configuration file). I use TT to fill in the blanks to create the actual configuration files, then move the completed files to the appropriate locations.

Works great.

In real life, I had a 4-level-deep data structure that TT handled brilliantly with its built-in hash key ability.