Template Engines Really DO Suck

[averagejoeguy]

I know you've all heard it before, but I just did this both ways for the hay of it and I realized how pointless all of these template engines are.

Firstly, I had to put the template together...

<table width="400">
<!-- BEGIN header -->
    <tr>
	<!-- BEGIN field_names --><th bgcolor="#FFCC33" align="left">
            {field_name}</th><!-- END field_names -->
    <th colspan="2" bgcolor="#FFCC33" align="center">Actions</th>
    </tr>
<!-- END header -->

<!-- BEGIN rows -->
    <!-- BEGIN row -->
    <tr valign="top">
		<!-- BEGIN field_values --><td>{field_value}</td><!-- END field_values -->
		<td align="center"><a href="{link_edit}">Edit</a></td>
		<td align="center"><a href="{link_delete}">Delete</a></td>
    </tr>
    <!-- END row -->
<!-- END rows -->

<!-- BEGIN pager -->
    <tr>
        <td colspan="func_add({num_fields}, 2)" align="left" valign="top">{pager}</td>
    </tr>
<!-- END pager -->
</table>

Programming syntax is programming syntax! It's like somebody said, "Well, what I need is a templating language... only less powerful than PHP, but also horrendously ugly... hmmm.. what to do?"

So, anyway, I had to write some code to handle the template...

$t =& new HTML_Template_Sigma(TEMPLATE_ROOT);
$t->loadTemplateFile("$class.browse.html");

function add($n, $m){return $n + $m;}
$t->setCallbackFunction('add', 'add');

foreach ($dao->fieldLabels as $key => $label)
{
	if ($orderBy != $key)
	{
		$direction = 'asc';
	}
	else
	{
		$direction = ($direction == 'asc') ? 'desc' : 'asc';
	}
	$url = sprintf('<a href="%s">%s</a>', $_SERVER['SCRIPT_NAME'] . 
                      "?orderBy=$key&direction=$direction", $label);
        $t->setVariable('sort_order', $direction);
        $t->setVariable('field_name', $url);
	$t->parse('field_names');
}


foreach ($records as $record)
{
	foreach (array_keys($dao->fieldLabels) as $key)
	{
    	        $t->setVariable('field_value', $record[$key]);
 	        $t->parse('field_values');
	}
    $t->setVariable(array('link_edit'   => $record[$daoIDField],
		        'link_delete' => $record[$daoIDField]));
    $t->parse('row');
}


$t->setVariable(array('num_fields'  => sizeof($dao->fieldLabels),
		    'pager'        => $pager->links));
$t->parse('pager');

I threw all of that junk in the trash can and went with this instead...

<table width="400">
<tr>
<?php

foreach ($dao->fieldLabels as $key => $label)
{
	if ($orderBy != $key)
	{
		$direction = 'asc';
	}
	else
	{
		$direction = ($direction == 'asc') ? 'desc' : 'asc';
	}
	$url = sprintf('<a href="%s">%s</a>', $_SERVER['SCRIPT_NAME'] . 
                      "?orderBy=$key&direction=$direction", $label);
	echo '<th bgcolor="#FFCC33" align="left">' . $url . '</th>';
}

?>
<th colspan="2" bgcolor="#FFCC33" align="center">Actions</th>
</tr>
<?php

foreach ($records as $record)
{
	echo '<tr valign="top">';
	foreach (array_keys($dao->fieldLabels) as $key)
	{
	        $value = $record[$key];
	        echo "<td>$value</td>";
	}

	$link_edit = $record[$daoIDField];
	$link_delete = $record[$daoIDField];

	echo <<<ACTIONS
	<td align="center"><a href="$link_edit">Edit</a></td>
	<td align="center"><a href="$link_delete">Delete</a></td>
    </tr>
ACTIONS;
}
?>

<tr>
	<td colspan="<?php echo (sizeof($users->fieldLabels) + 2); ?>"
             align="left" valign="top"><?php echo $pager->links; ?></td>
</tr>
</table>

And then to get it into my framework...

ob_start();
require("myapp/dao/templates/$class.browse.php");
$browser = ob_get_contents();
ob_end_clean();

The only benefit I can see is when you can't trust the authors of the template file, but I haven't encountered that scenario. In any case, those authors are going to have to follow rules you set down for them. They could just as easily insert foul language, etc.

In the end, I think it comes down to trust, not technology.

[thevirus]

May I ask what is a template engine? Somthing that automatically generates templates or a search engine for templates?

I had the idea of a php code that allowed you to customize template banner nav bars footer... and then get the code for it. Is this what you are talking about?

[Phil.Roberts]

May I ask what is a template engine? Somthing that automatically generates templates or a search engine for templates?

Try using the search. It's hardly a new or unusual topic.

Anyway, embedded HTML is a quick and dirty solution. But when you application is large and has common elements spread over multiple pages then it quickly becomes a bane. Personally I can't stand having HTML code mixed up with my application code.

I like using WACT for my templating personally:

$Page =& new Template('/index.html');

# Latest Album Reviews

$LatestAlbumReviewList =& $Page->getChild('LatestAlbumReviewList');

$LatestAlbumReviewList->registerDataSet(

    ReviewDS::getReviewsByForumId(10)

);

$Page->display(); 

    function &getReviewsByForumId($forum_id) {

        return DBC::NewRecordSet("SELECT t.*

                                  FROM " . FORUM_DB . "." . FORUM_TABLE_PREFIX . "topics t

                                  WHERE t.forum_id=$forum_id

                                      AND t.approved=1

                                  ORDER BY t.tid DESC

                                  LIMIT 0, 5");

    } 

<h3>Live Reviews</h3>
    <ul>
    <list:list id='LatestLiveReviewList'>
      <list:item><li><a href='reviews.php?review_id={$tid}'>{$title}</a></li></list:item>
    </list:list>
    </ul>

[mwmitchell]

Personally, I think that the php is much more "ugly" than the other code in this example. Also, there are many different engines out there, with all kinds of syntax. T.E.'s are good for some things. It all depends on what you are doing.

Mmmm, WACT looks good!

Matt

[josheli]

<?php



$reviews = getReviewsByForumId(10);

include 'index.html';





function getReviewsByForumId($forum_id) {

  $sql = 'SELECT t.* 

    FROM ' . FORUM_DB . '.' . FORUM_TABLE_PREFIX . 'topics t

    WHERE t.forum_id='.$forum_id.'

    AND t.approved=1

    ORDER BY t.tid DESC

    LIMIT 0, 5';

  return sqlSelect($sql);

}

?>



<h3>Live Reviews</h3>

    <ul>

        <? foreach($reviews as $review){ ;?>

            <li><a href='reviews.php?review_id=<?=$review['id']?>'><?=$review['title']?></a></li>

        <? } ?>

    </ul>

[Phil.Roberts]

Originally Posted by josheli

As I said though. I don't like having PHP & HTML mixed up. I have preferred tools for working with both and I like to keep them as seperate as possible.

[josheli]

well, now instead of just php and html mixed up, you have php {$tid}, html <h3>, and a propietary template language </list:item> mixed up. the great thing about php is it's both a template language and a scripting language.

if you're disciplined, you can create html "templates" with only includes, foreach, ifelse and short tags, which would not be your "application code", just your preferred templating mechanism, and faster to boot.

but it's an old, tired debate, so to each his own.

[Widow Maker]

Personally I can't stand having HTML code mixed up with my application code.

Never used WACT before, still to find the time to look at it properly, but it has had excellent reviews

[been]

Well, entire wars have been fought over the issue "using php as template language or not".
You could do a search on "smarty" and member "voostind" and come up with a thread that, for me at that time at least, was a serious eye-opener, considered to be a mandatory read amongst a lot of SitePoint-PHP members.

I used to lean towards the idea that external template engines were completely useless, PHP was a fast and powerfull one on it's own.
Now, I'm definitely convinced this is not true.

Whether TemplateView is "THE way" for presentation in an application or not, is another discussion alltogether, but I think it's safe to say that it has proven it's usability in a large majority of the up&running websites out there.
The question to ask becomes: "What language should be used to make up the template?"

I think the main reasons for using templates are achieving some sort of seperation between application- and presentation logic on one hand and the ability to externalize the maintainance of that template on the other (so a graphics designer can work on the template, while a programmer can work on the application code).

Today I believe that PHP is not entirely suitable for this for reasons that now seem so obvious, I'm wondering how I could overlook them:

- Using PHP ties you to some extend to... err.. PHP. I'm not implying that you should be able to take a template from a php website and copypaste it into an ASP.NET application or something. Although it would be nice, I hear this little voice whispering it'll remain whishfull thinking for the time being. What I am saying is that a designer should be able to take the template, open it in his/her favourite design tool (dreamweaver or whatever), start editing away, safe it, copy it to the template directory, and the application would have the different layout, without having to touch the code if not necessary.

Although a tool like dreamweaver would recognize the php tags in the template, it would not be able to render a complete visual of the php code in there, unless it was connected to some test server, which opens up other problems of course.

What I'm trying to get across is that PHP hasn't exactly a parsing-friendly syntax, nor has it the large supportive base a declaritive language such as x(ht)ml has. This makes that PHP code is mainly suitable to be parsed by the PHP parser and consequently renders it useless as widely-acceptable template language.

- I believe the application logic for generating native PHP templates at runtime becomes unnecessary complex, for example: letting a user create his/her own template for a newsletter via an online web form and stuff like that.

- PHP syntax is that of a programming language. No matter how much more natural this may feel to us, programmers, it simply does not hold up for designers, who are very much more familiar with a declaritive syntax.

To conclude, I think native PHP templates can be of use in some applications (I've used them alot myself), but I'm convinced I should not put them in my "standard PHP toolbox of reusable components" (mmmh "SP-Torc", nice name for a.... framework ), they're just too dependend on PHP itself.
I think I'd prefer an XSLT solution, or an engine like PHPTAL or WACT.

"Native PHP templates", they sound really yammy, but in the end, I believe they do not cut the mustard.

[mwmitchell]

I honestly believe that there is not really a difference. I think it's all in the way you construct your templates. If you have a template (regardless of syntax) full of 'if', 'foreach', 'loop' etc... It's not going to hold up to a designer that doesn't know what's happening, working with Dreamweaver or whatever. Through the "Design" view in Dreamweaver, if you cut out a tag (Smarty, PHP etc...) and place it somewhere else, and it was part of a loop or conditional... BOOM! Doesn't work.

If you use compositional/component based templates then things get much better. It doesn't matter what template language/system you use. If you want to display a list of users, make the list a seperate tag by itself. The tag would be:

<? $this->show('user_list'); ?>
OR
{$USER_LIST}

Now, if you cut that out and paste it somwhere else in a templates using Dreamweaver, all is good. You can put it wherever you want. If the designer really wants to mess with the style of the list, they should know that it's a block that's a little more touchy and should be edited with care. But even in the seperate block (user_list example) it's safe to edit. There is nothing to move around, just style. Not really layout. Because it's abstracted into it's own structure.

What I'm saying is that keeping things compositional, putting looped blocks into their own components, and keeping logic out you have a pretty nice template regardless of the language/syntax being used.

Just my 2 cents!

Matt

[been]

I certainly agree that a Tag/Component-system seems to be the preferable way of implementing TemplateView. But at that point the "native php way of templating"-implementation seems to become as complex as any other template engine, thereby defeating the "simplicity" argument the native php template machine originally had going.

<? $this->show('user_list'); ?>
OR
{$USER_LIST}

Now, if you cut that out and paste it somwhere else in a templates using Dreamweaver, all is good. You can put it wherever you want. If the designer really wants to mess with the style of the list, they should know that it's a block that's a little more touchy and should be edited with care. But even in the seperate block (user_list example) it's safe to edit.

This is exactly one of the points were I see php as a template language fall somewhat short; yes it's possible to safely copypaste that tag or that place holder, but a designer cannot see the user list. With a system like phptal or wact component-based templates, you could fill the template with some bogus, static data and work on that: the designer would actually see a user list in the "Design" view, or whatever it's called, and the template system would ignore the bogus data. I'm assuming a lot here as this is much more from having read the homepages and browsing through the documentation of both systems, rather than having hands-on experience with any of them.

Further more, I think the source language the template is written in, does in fact matter very much; compared to x(ht)ml, php is almost an obscure vendor-specific format.

[mwmitchell]

Originally Posted by been

This is exactly one of the points were I see php as a template language fall somewhat short; yes it's possible to safely copypaste that tag or that place holder, but a designer cannot see the user list. With a system like phptal or wact component-based templates, you could fill the template with some bogus, static data and work on that: the designer would actually see a user list in the "Design" view, or whatever it's called, and the template system would ignore the bogus data. I'm assuming a lot here as this is much more from having read the homepages and browsing through the documentation of both systems, rather than having hands-on experience with any of them.

I agree with your points, but in each of the component templates you'd be able to see the list structure, if coded that way. You can make a list (pre-formated) in php code, and display it in either/or Smarty or php. It'll still be some non-editable list tag.

But if you make a template script and a separate template file (html that determines the view structure) then it's a real "template", and can be edited. And seen in Dreamweaver design view. The same thing still exists in any templating language when you have conditionals and/or loops. If something gets moved, theres a chance it won't work. I agree that a template language could look/easier to understand better than raw php, but nothing a few php simple lessons couldn't teach. I'm not cheering on php as a template engine, I just think it's all about how you put the templates/blocks together.

Matt

[been]

I agree that a template language could look/easier to understand better than raw php, but nothing a few php simple lessons couldn't teach.

In regards to human beings, I can only agree, but how is one going to teach all the tools that template designers use, 'a few simple php lessons'?

[mwmitchell]

Well, really all there is for main templates is printing.
<?= $tag; ?>
{$TAG}
And then for the components, add conditionals and loops. It's all the same in a template language or php. With tiny differences.
{if $name eq "fred"}XXX{/if}
<? if($name == "fred"){ ?>XXX<? } ?>
I guess it's about what the designer feels comfortable with. If the only the needed tools are taught for templating in php, then to me the difference is like the difference between an automatic transmission and a straight stick. There are many pros and cons to either side. I'm not dis-agreeing with what you are saying at all. Maybe just thinking out loud here.

But it's all really a matter of taste if you've built good templates to begin with.

Matt

[been]

I'm not dis-agreeing with what you are saying at all. Maybe just thinking out loud here.

Same here, and my apologies if I give the wrong impression, that certainly is not my intention.

Still, I cannot seem to shake the feeling that php as the language of a source template is a "wrong" decision.
Another analogy just came to mind: Doc comments:
You write the PHP source code with the tool of your choice, which should be your god/mama-nature given right as a developer/develop team.
Now, what's so productive in a tool like phpdocumentor is, that the source file, that same file that the developer's tool created, can be read by the documentor and it'll generate the documentation, there is no need to modify the source file in any way before it passes through the documentor.
The analogy appears when in the former paragraph "developer" is replaced by "designer", "PHP source" by "template source", "phpdocumentor" by "template engine" and "documentation" by "view" ("view", dare I say it )


Maybe using php as the language in the source file of the template is the result of looking at the template from the application-development side.
For the template, I think, we have to look from the presentation-development side and that's a different domain, with different tools, with different habits, with different standards, languages, best practices, etc... More and more I'm getting convinced that PHP, as far as language of the template source file is concerned, has no business whatsoever in that domain, it seems to create an unnecessary dependency.

<div id="userlist" class="DataList">
 	<div class="UserData">
 		<span class="UserName">George Bobo</span>,&nbsp;
 		<span class="UserEmail">georgeb@example.com</span>
 	</div>
 	<div class="UserData">
 		<span class="UserName">Mark Fliptie</span>,&nbsp;
 		<span class="UserEmail">mark@example.com</span>
 	</div>
 
 	...
 
 </div>

This template is without a doubt visually editable by any web designer's tool. It also can be read without problem by a template engine after which data can be bind based on values of the tag attributes. It can also be sent to a client to give them a visual of the work you're doing for him. All without prior modifications or processing of the source file. Reading and parsing takes a lot of time of course, so you cache the output, but, when read from cache you cannot access the tags/components, so you need an intermediate process that turns the template into a format that can be read&parsed more quickly than the source file, but still produces an accessible component to the application, a compiler if you will.

It seems that the native php template could in fact be seen as output of such a compile process, consequently, it does not make much sense to manually create the output a compiler could (and should) be creating, it sounds like writing an .exe in notepad or something .

To stick with the automatic vs. manual transmission analogy for a moment; What is the goal we're trying to achieve there? I think it's: to drive, to get from one place to another. So I would prefer automatic transmission: push the "start" pedal and when arrived, push the "stop" pedal, I don't want to have to worry about sticks and gears (it's a bloated interface, or, maybe better; too much internals are exposed that should have been encapsulated, just to throw in the analogy-in-analogy-effect). Of course, driving a manual transmission is way more fun, but "having fun" wasn't the original goal.


And yes, I do get
a) that incredible feeling of deja-vue
b) the sense that there's a wacty smell in the air
c) the idea I'm running a few years behind the facts

[mwmitchell]

Hey,

Nice post, very good points. I see what you mean about the transmission analogy!

I do agree with what you are saying. I think you're right also that it's easy to think php templates are good enough when you are the application designer.

Do you have the code available for parsing the template you posted? Is that WACT?

Matt

[been]

Do you have the code available for parsing the template you posted? Is that WACT?

WACT is old skool mister, this is a radically new way of templating, the best thing since sliced bread, I call it Hilarious Template-Moronic Language, codename HTML. I envision that the code for parsing it will find its way into everything; mo and other zilla's, blindernet explorer, the fox, the lynx, the birds, even the opera will incorporate systems to parse this kind of template!

Nerdy jokes aside, no, I do not have any code as such, was merely thinking out loud. Still, parsing such a template with WACT's templating system should be pretty straightforward?

[Buddha443556]

Originally Posted by been

Maybe using php as the language in the source file of the template is the result of looking at the template from the application-development side.
For the template, I think, we have to look from the presentation-development side and that's a different domain, with different tools, with different habits, with different standards, languages, best practices, etc... More and more I'm getting convinced that PHP, as far as language of the template source file is concerned, has no business whatsoever in that domain, it seems to create an unnecessary dependency.

Maybe there's a side missing? What happen to the end user? I thought modern programming was all about making the end users happy. Maybe those things I heard about Extreme and Agile Programming were just hog wash.

The end user isn't usually the web designers or the programmers or even the guy paying your salary when it comes to web applications. Does the end user even need a template engine? How many times is the end user going to use it? My customer usually have maybe six or seven templates to cover the holidays. The guy who changes the templates doesn't want do any editing. This end user just want to select Christmas, click a button and see snowmen. The web surf he just see's snowmen doesn't care about templates or the buttons that are used to change them.

Maybe we need to change our focus?

Of course, it's 3 in the morning so there's a good chance I'm totally off base.

[TheDragonMaster]

Hi. I`m not that far with PHP as you all are, but I prefer a Template-Engine over nativ PHP in Templates.
I used native PHP as Templates a short while, but I don`t like it at all...
I prefer using a small Template-Engine, wich allows me to use some things like If and Switch. Also to call a PHP-Function, but that`s all.
I think it "feels" better, when using a HTML-alike Syntax in Templates, than PHP.
I`ve build my own small parser, which translates this Template-Language to PHP-Code and saves it into a PHP-File, which I only have to include and be happy.

Almost like vBulletin or Woltlab are doing it.

But in fact I don`t build "one Person", things... so I have to think of the people, which may use it, and wich may want to customize the look of it.

[dagfinn]

Originally Posted by been

What I'm trying to get across is that PHP hasn't exactly a parsing-friendly syntax, nor has it the large supportive base a declaritive language such as x(ht)ml has. This makes that PHP code is mainly suitable to be parsed by the PHP parser and consequently renders it useless as widely-acceptable template language.

Excellent point which I haven't seen raised before. Also not mentioned here is the issue of security. In many cases, anyone who is able to edit a template with full PHP capabilities could for instance be able to add code to give themselves privileged access to the application. If you leave the template editing to, say, a company that specializes in Web design, that is potentially dangerous.

[Buddha443556]

Originally Posted by dagfinn

Excellent point which I haven't seen raised before. Also not mentioned here is the issue of security. In many cases, anyone who is able to edit a template with full PHP capabilities could for instance be able to add code to give themselves privileged access to the application. If you leave the template editing to, say, a company that specializes in Web design, that is potentially dangerous.

That funny I thought the reason for using a "template engine" was becasue web designer should not have to learn PHP? Now the web designer knows PHP but we can't trust them with PHP? Where the logic? If the web designer knows PHP then we don't need a "template engine," right?

Someone has to be responsible for security, this responsible person would still be reviewing the templates weather they're PHP or Smarty or whatever.

[been]

Hm, I read it is potentially dangerous, which is something completely different than "We can't trust web designer with PHP".

Maybe the issue of security will be more clear with an example (I know, examples are dangerous, too much assumption, but still):
Suppose you have a commercial website which exposes a web based administration interface where people (after paying exhuberant amounts of money of course ) can build their own personal home pages. The main design of their homepages will be made up of templates they upload to the server.

You see, once the creation and/or modification of a template is "out of our hands", it does become a potential security risk. Actually, you are agreeing with this since you stated that some person, responsible for security, should review the template.
Now, stop right there and think about it for a minute: you are actually willing to pay someone to manually go through some ASCII text and check for certain patterns
I will let you in on a little secret; most computer languages are pretty good at that, if used correctly, a piece of software can do that for you in such a small fraction of the time it takes a human being, you'll need Hubble to actually see that fraction, and it will do so more acurately and consistently

In that light, all the K-lines of code you think you are saving by using php as template language, well, don't even think about it, it will have to go in there, because you have to parse those php templates to make sure they do not contain any malicious code. Funny thing happening now: Now, you are actually writing a php parser in php, to parse some stupid php-template file ... how useless is that

All in all, this belongs to the templating system, which is the application-develop domain, and has nothing to do with the actual language used in the template.

[Buddha443556]

Originally Posted by been

Maybe the issue of security will be more clear with an example (I know, examples are dangerous, too much assumption, but still):
Suppose you have a commercial website which exposes a web based administration interface where people (after paying exhuberant amounts of money of course ) can build their own personal home pages. The main design of their homepages will be made up of templates they upload to the server.

Well can't actually argue with your example, because a template engine is actually needed in such an application. Of course, look who's benefiting from the template engine? The actual end user.

Maybe the problem is how the template engine pattern is being applied in particular applications?

[been]

The example wasn't meant to be argued, it was just there to illustrate the fact that a security risk potentially exists, nothing more.


In light of this whole "not another "not another "not another template discussion" discussion" discussion", I wanna share this "new" develop methodology I'm about to invent: Although I'm not married, I've decided, on grounds of funky terminology, to call it "Tripple-tee-double-you", TTTW, stands for "Talk To The Wife":

My girl friend is not a web developer or a web designer, but she does know her way around a computer, windows and app's like word and the family (a lot more than me I might add), etc...
As I said before, that famous voostind thread was a real eye-opener to me, I just wanted to share the revelations I had at the time and started to explain the concept of a template, then I told her a few things about a programming language like php and "how useless all those other templating systems really were". Overall she grasped the general idea and she was very happy for me.

Imagine the look on her face when I told her "you know that php templating thing I told you about a year ago or so?" "yes" "Well, I was wrong", again I tried to explain (somewhat in the same chaotic way, although luckily in my native language).

Now my girlfriend is extremely good in imagining herself in someone else's shoes, she also has the ability to remain quite objective and sober. You know what she started thinking when I told her about php as language in a html template? Arrogant
I think she is absolutely right. You see, she imagined herself as a webdesigner and immediately felt that something was being "forced" upon her that really shouldn't be.

I honestly believe we shouldn't be doing this: enforcing things upon other's just isn't a productive way to interact for humans. Well, it could be, but only to the enforcing party.
For the enforced party, I think it's like those little annoyances building up that Joel Spolsky talks about sometimes.

I find myself drawing a somewhat strange sounding conclusion: Since it's really about human beings, the only acceptable template language, is the language the template file is originally written in.

PS: I do realize that the native php template can work for you, I've been there, in reality I'm still there, and in some ways it is working. Just be sure to remember this: When someone tells you that your php templating system isn't working in a development-design realm-seperation, do not go arguing "what's so difficult about learning a few php instructions/syntax?", when you do, it's a sign, a sign you are willing to enforce your realm on the other. It is not a good sign.

PPS: on my TTTW-methodology, I realize it's a bit flakey, if you happen to be single for example, you're screwed.
But then, that's a goooood thing, isn't it

[lazy_yogi]

I was thinking about this a while ago and mentioned it to a friend, giving this example

<h1>{$word}<h1>
<ul>
  <loop>
  <li>{$element}</li>
  </loop>
</ul>

and he said something like "it's all the same, just diff sytax for the same thing"

and I though "he's right". I mean is that really different to:

<h1><?=$word><h1>
<ul>
  <foreach($list as $element):>
  <li><?=$element?></li>
  <? endforeach ?>
</ul>

The only difference is that programmers that havent learnd about templating don't seperate it out - which unfortunantly is 99% of php programmers. Other than that, it's exactly the same. Either way your'e gonna need a way to loop through things, a way to handle if statements and a way to print variables. The front end guy has to deal with one of them. It's not easier fot them to deal with smarty (or any other tamplating system - cuz they're all the same) than it is with those handful of equivalent php statements.

As he said, "it's all the same, just diff sytax"