Most PHP developers (and other web developers too) seem to evolve on a similar path which goes like this:

Step 1: take HTML pages an add PHP tags into them.

Step 2: Realize that on a large scale this is getting very hard to maintain.

Step 3: Learn about the MVC (Model View Controller) paradigm and begin to think it’s cool.

Step 4: Use Smarty or another templating engine like that.

The way most of those templating engines work is basically this:
a) Do a ton of PHP processing in the framework and fill in variables.
b) Call smarty and let it fill in variables in a template.
c) Send the output.

The issue here is that during steps a and b, nothing is sent back to the user. The user is just waiting for a response. Sadly enough, steps a and b will take a lot of precessing time. So the user will wait quite a long time before he gets any feedback on his action.

Even worse, when the application gets bigger, step a will take even more time!
And the more complex page you request, the more time you’ll be left in the dark…

This is why I don’t like all those mainstream templating engines. I want to send output back to the user as soon as possible. I want to send the page header at the begining of step a. And as soon as something has been processed and is ready for display, I want to send it out.

The global processing time will be approximately the same, but if the user sees content begining to display immediately, instead of all the content displaying at once 2 seconds after clicking, he will get the (false but humanely useful) impression that the application is faster. (Please do not say AJAX here, it is so not my point :P)

I’m not saying MVC is a bad paradigm, I’m saying most implementations of MVC are flawed, and Smarty is the most common example of this in PHP. Because they do the M & C stuff and then they do the V (view) stuff at the end. In my opinion they definitely need to interleave all this a lot more.

In evoCore (b2evolution’s framework) our approach is to have the Controller really control the processing flow. In other words: for every block of information the View wants to display, the Control will process data from the Model and immediately pass it to the View in order to display the result block by block.

Of course, this has drawbacks: you won’t be able to change the block order of the output if it’s hard coded into the Controller. But really, that’s okay to some extent. Who really needs to move the global header and the global footer for example? This is what we use for the back-office.

However, for the front-office, we want more customization, and we want people to be able to rearrange blocks in any order. In this case we have a little more complex processing, where the View actually calls the controller everytime it needs to display something.

Anyway, in any situation, my point is: the View should not be handled last.

Comments from long ago:

Comment from: fplanque: dev blog

Rasmus on templating enginesAt PHP Forum, Rasmus said this about the “templating engine question coming back every year”:

PHP is a templating engine by itself. Adding another templating engine on top of it just doesn’t make sense. The only situation where it makes sense, is …

2005-11-16 23-09

Comment from: Sylvestre

Well, your argument is true for Smarty but I don’t think it is a reason by itself for not using this template system…
Moreover, in many cases, you can use the caching system of smarty which makes this problem disapearing…

2005-11-25 04-45

Comment from: Achim

I think the time a page needs to be genrated usually can be neglected compared to the time the page spends “in the net” between the server and the browser. If it is not a very complicated processing I think the user waiting for a response will see no difference between a page which created the view at last and a page which creates the few “on the fly”.
If the server slows down so much, that there is a significant difference between those two ways to create a page it would be perhaps better to think about upsizing the server. You say: “The global processing time will be approximately the same” - so in this case the user definitly HAS to wait. And in my opinion it does not make such a great difference, if he gets the bits of information everytime they are created or at the end - if the global processing time is too long, then it doesn’t matter in what way the data is send to the user. You then should consider about the whole application architecture, the server environment and the database connection, not about some psychological tricks for displaying data. Just my opinion.

Achim.

2005-12-12 21-10

Comment from: Tali Me Banana

Well,

It doesn’t seem like Francois has even used Smarty.

I’ve been using Smarty for the past 4 years and I can tell you that it most certainly does not slow down steps a and b. Run your own benchmarks and try it. I’ve compared a decent sized script with and without templates and got results so close to each other that even time itself could not discern the difference.

To top it off, add caching on there and you can do so much more than you could without Smarty. I recently took a very complex SQL query (on good hardware) and turned it from a 3.5 second execution time to a 0.2 second run time with Smarty and caching.

You’d be hard pressed to convince me Smarty slows things down after having such extensive experience with it.

Oh ya, tried implementing APC cache with b2evo and it breaks. Better get that fixed before APC goes into the core of 6!

2006-02-03 08-56

Comment from: loconet

I agree with Smarty having its problems but I’m not sure why you are associating MVC with Smarty. Smarty is not an MVC implementation. Smarty is just a templating engine. MVC (Model-View-Controller) is a design pattern which may or may not use Smarty in the case of php. MVC is a higher level of abstraction which although may use a templating engine as part of its view function, is much more than just “templating”. So to say that MVC templating is inefficient is just inacurate.

2006-03-09 18-55

Comment from: François Planque

OKay I need to clarify a few things.

I am not ranting at MVC, I am ranting at poor MVC implementations. And Smarty is a poor implementation to me.

Also I am not claiming Smarty slows down steps a & b. I am claiming that if a & b are already long, then Smarty makes it just look worse by not sending any output before the end of b, whereas not using smarty would allow to send output much earlier.

Finally, cacheing is cool but it won’t help much as soon as you have somehting that’s a little more than dull website updated once every… day? …but something more like a user customized dynamically updated application: you just can’t cache effectively something that changes every few pageviews.

2006-03-09 20-46

Comment from: Brian

First of all…

Absolutely nothing prevents you from doing:

$smarty->display(‘header.tpl’)

at the top of your php script and then continuing on with the rest of the logic.

Second of all…

If there is a 2 second delay between the time your visitors see the header and the rest of the page, many users will perceive this to actually be SLOWER compared to: clicking a link, seeing the status bar of their browser show “Connecting to site…” and then 2 seconds later the page draws instantly.

Indeed, by not sending them anything until the entire page is ready, at least they still have the last page to look at and occupy their mind, instead of a banner and set of links they’ve already seen before and a large blank space underneath it, taunting them.

Plus, with the first way they KNOW your site takes 2 seconds to render one page, whereas with the latter method they may simply attribute the 2 second load time to a network connectivity issue that could be anywhere between their connection and yours.

2006-07-03 23-45

Comment from: David

I consider that smarty has everything PHP / MVC developer might dream about. If there are things that you people don’t like in it, there is a way to make a plug-in. However, since smarty supports {php}{/php} in its tpl files as I think there is no need for that. When I have to do something that Smarty doesn’t support, I do write php code in template files, I can even globalize php class variables, {php}global $auth; .. . {/php}

2007-01-24 20-54

Comment from: Skrol29

Just to let know that not all template systems works like that.
TBS (TinyButStrong) let you merge the parts of your template step by step. Your steps in your order. The MVC model (or other) makes no problem like this.

By the way, TBS is alos the only template engine to enables WYSIWYG templates.

2007-02-28 23-05