Template systems based on original template language are pretty popular amongst web tools such as frameworks or CMS (Content Management System). But are they really necessary? Moreover, don’t they slow down the learning curve by adding complexity over complexity?
Templates engines in web context are pieces of software designed to split the code of a web application between logic (database access, data processing) and presentation (HTML, CSS) in order to gain in maintainability. Templates engines often comes along with a specific template language with an original syntax and a fixed set of functionalities.
I’ve always been amazed by the arguments in favor of using a Template system with an original template language in a framework or a CMS. Let’s see if we can put them in perspective.
“No [insert programming language here] knowledge is required to manage templates”
This example is an extract from the “Why Use Smarty?” page. The argument in itself is not wrong, it’s just that it’s irrelevant with web development, whichever is the professional context:
- In an agency, a web site project usually involves a web-designer doing the graphic part in a PSD file, an integrator doing the corresponding HTML/CSS, and finally the developer tying up all together with the chosen software. The integrator never ever touches the software, so he simply does not have to learn the template system
- As a freelancer, all the above is done by the same person
For both context the result is identical: the one having to manage templates is always the one knowing [insert programming language here]. The template language is just another complexity added to the project and extending the learning curve of the underlying software.
“Entire templates can be cached, producing the fastest rendering time of any dynamic system”
This another example is an extract from ExpressionEngine Features page. For me, caching systems are responsible for many annoying bugs not easily fixed in complex page layouts where parts of the page must be cached, and others don’t. But why use a caching systems in the first place? To compensate performance loss due to template processing? Strip the template engine, and you’re free.
This applies also when there is a template pre-compiler to improve performance. In this case, the developer has either to deactivate the compiler, making page load during development slow, or cleaning the compiler cache after each modification made to a template, which can happen a lot during a web site development.
Plus, there already is lower-level intelligent caching systems that are much more efficient to reduce the page load time, and stacking caching systems is not the best way to keep a web site well maintainable.
“This is by design: the template system is meant to express presentation, not program logic”
This example is an extract from the documentation page about Django’s template language. In an ideal world, this should always be true, even more when the underlying software is based on MVC pattern which separate data logic (Model), presentation (View) and application logic (Controller).
Unfortunately we’re not living in an ideal world, and since it’s more convenient to fully document a template language than the entire software, some developer find it easier to implement some part of the application logic directly in template language. Sometimes it’s the software that is difficult to extend by (poor) design.
In any case this is obviously not desirable, and template languages don’t help to keep a clean separation between the three parts.
“Clean Error Messages”
This final example is an extract from Twig template engine home page. Original syntax means original errors and original debugging. Everyone knows how to debug the logic part of an application because it’s written in a customary language. But when it comes to template language debugging, you can face unexpected difficulties because of the template engine error handling or the lack of proper debug tools. This adds again another layer of complexity when you need efficiency the most.
In my opinion, template engines should not double already existing language features like error messages and debug tools. At least because third party debugging tools won’t know how to handle template engine custom errors, for example.
So, are template engines bad practice?
Don’t take me wrong here, I’m not saying that template engines should not be used. I’m just saying that when there is a template language involved, the benefits from using such engine can shrink, if not vanish. Learning curve slowing, cache bugs, and overall development time increase are more likely to happen than without any template engine.
Still, there is some getaway, template engines that are based on the very own language of the application on top of which they are built. If I had to cite only one, I would say that Worpress does a pretty good job in this field. When writing templates, you have the choice to use specially crafted PHP functions to ease template development, or to use native functions if you have special needs. Both methods can work together seamlessly to achieve expected results without too much effort.
Again in the PHP field, Symfony framework is using simple PHP templates, at least in the 1.4.x versions. Sadly Sensio Labs introduced the Twig template engine in version 2, making it less attractive from this point of view (and others, but I don’t want to spoil the fun for those who are discovering Symfony2).