Why Should I Use Templating System in PHP

Why should I use templating system in PHP?

Yes, as you said, if you don't force yourself to use a templating engine inside PHP ( the templating engine ) it becomes easy to slip and stop separating concerns.

However, the same people who have problems separating concerns end up generating HTML and feeding it to smarty, or executing PHP code in Smarty, so Smarty's hardly solving your concern separation problem.

See also:

• PHP as a template language or some other templating script
• What is the best way to insert HTML via PHP

What's a good templating system for PHP?

Smarty

---

I've found it to be fast, easy to use, and easy to install (even in a shared-hosting environment). It also doesn't require that you use validating XHTML which is handy sometimes (although I think the template engines that do require valid XHTML are probably faster.)

It's really nice to have your content in one place and code somewhere else.

Plus you're not limited to just HTML. I've used Smarty to generate XML and even SQL.

Pure PHP/HTML views VS template engines views

"Depends" is the answer to all your questions.

What is "faster"? Execution time? Development time? Maintenance? Memory overhead? A mixture of them? A template engine is usually trading in some performance (speed, memory) for better development and maintenance.

If you are talking about purely dynamic templating (meaning: template evaluated on every request) PHP will outrun any template engine. This is a nobrainer, really. If you're taking caching into account, a template engine like Smarty may help. Caching is nothing you couldn't implement yourself in plain PHP, though. With Smarty it's just been done for you (and on a far more sophisticated level than you possibly would).

If you are using a framework, say Symfony, it might be wise to use Twig, as Twig and Symfony are tightly integrated. Sure you can use Smarty or plain PHP. The question here is: is it practicable?

Caching makes sense when building sites from datasources like a database or remote APIs. What you are really saving (in a sense of reducing) here are database calls, intensive calculations, etc. Check if you have any time-intensive functions running to build your site. If so, use caching (if you can).

Knowing development/maintenance/convenience/performance trade-offs, I would (always) recommend using a template engine. Being a Smarty developer, I'll, of course, suggest using Smarty. That is unless you're using Symfony, then you might be better of with Twig. Or some other framework featuring some other template engine.

Please ignore posts like Smarty vs. Twig, as they only compare a very limited view of the engines. Don't trust benchmarks you haven't faked yourself™.

In general, though, Smarty 3.1 is a bit faster than Twig. Twig is doing a lot of stuff at runtime (being the time when a template is executed) that Smarty does on compile time (being the time when a template is prepared for execution). Twig is not really pissing away speed here. Twig needs to do certain stuff at runtime by design. They traded a bit of performance for a bit of "convenience" (Accessing arrays and objects with the same notation, for example).

PHP template system vs javascript AJAX template

I've worked with similar design pattern in other projects. There are several ways to do this and the task would involve managing multiple project or application modules. I am assume you are working with a team of developers and not using either PHP or JavaScript MVC framework.

PHP Template

For many reasons, I'm against using “search and replace” method especially using server-side scripting language to parse HTML documents as a templating kit.

Why?

1. As you maintain business rules and project becomes larger, you will
   find yourself reading through a long list of regular expressions,
   parse HTML into DOM, and/or complicated algorithms for searching
   nodes to replace with correct text(s).
2. If you had a placeholder, such as {title}, that would help the
   script to have fewer search and replace expressions but the design
   pattern could lead to messy sharing with multiple developers.
3. It is ok to parse one or two HTML files to manage the output but not
   the entire template. The network response could be slower with
   multiple and repetitive trips to server and that's just only for
   template. There could be other scripts that is also making trips to
   the server for different reason unrelated to template.

AJAX/JavaScript

Initially, AJAX with JavaScript might sound like a neat idea but I'm still not convinced.

Why?

1. You can't assume web browser is JavaScript-enabled in every mobile
   or desktop. You might need to structure the HTML template in few
   ways to manage the output for non-JavaScript browsers. You might
   need to include <noscript> and/or <iframe> tags on every page. And,
   managing alternative template for non-JavaScript browser can be
   tedious.
2. Every web browser interpret JavaScript differently. Most developers
   should know few differences between IE, FireFox, Chrome, Safari, and
   to name few. You might need to create multiple JavaScript files to
   detect then load JavaScript for that specific web browser. You
   update one feature, you have to update script for all web browsers.
3. JavaScript is visible in page source. I wouldn't want to display
   confidential JavaScript functions that might include credentials,
   leak sensitive data about web services, and/or SQL queries. The idea
   is to secure your page as much as possible.

I'm not saying both are impossible. You could still do either PHP or JavaScript for templating.

However, my “ideal” web structure should consist of a reliable MVC like Zend, Spring, or Magnolia. Those MVC framework include many useful features such as web services, data mapping, and templating kits. Granted, it's difficult for beginners with configuration requirements to integrate MVC into your project. But in the end, you could delegate tasks in configurations, MVC concepts, custom SQL queries, and test cases to developers. That's my two cents.

---

Related Topics