Log in

No account? Create an account
entries friends calendar profile It's Me Previous Previous Next Next
The Autobiography of Russell
Life from a different perspective
Templating Engines: The Wrong Solution to the Wrong Problem
I'm here today to explain why templating engines are the wrong solution to the wrong problem. Their popularity among various circles waxes and wanes, yet they persist. Some designers and programmers love them, and some hate them. I'm going to go through some of the common reasons why they're loved then expand on why and where they go wrong.

Using a template engine allows my designer to design without learning how to code
False. Your designer still has to learn the engine's specific syntax and its specific gotchas and how-tos. Some designers won't want to go past designing, and I respect that. They shouldn't have to. For the ones that do, though, you've effectively crippled them and required that they start over to go any further. Not all template engines are created equal and some force your designers to copy and paste instead of reuse display logic.

Using a template engine frees my programmer from worrying about the design.
False. Your programmer now has to worry about two different domains. Who is going to maintain the template engine when something breaks or your designer needs to do more than it natively allows? Designers that want to go beyond just designer are now unlikely to tackle a whole other language just to add an additional feature they need for the display logic. When a designer writes something, gets an error, and can't find a way around it, who are they going to bother to help fix it? Your programmer. Now your programmer has to know the template's syntax and implementation as well.

A template engine allows me to separate my application logic from my display logic.
True, but a template engine is not required to do this. I suspect many of us first learn about this concept by using a template engine which helps artificially enforce the paradigm, but the same can be done without a template engine. Take PHP for example, which was originally designed to be a template engine. You can put your HTML in one PHP file, your logic in another PHP file, and simply pass the variables necessary for display to the HTML file and iterate and echo them without any of the logic for handling responses or pulling data from the datastore. Your designers only need to learn about the same basic concepts of PHP that they would have in the template's syntax, such as if, foreach, and echo.

A template engine allows me to run template code from untrusted sources.
True and false. A lot of template engines make this claim, yet the reality is they are vulnerable to exploits just like the base language is. Incorrectly set up, poorly developed, or just edge cases not caught by the developers can allow malicious users to get through. If your designers are paid and working for you, yet you're concerned about this, then you have bigger problems. The only time a template engine is valid in this case is if the content is coming from random users online, in which case a template language is probably more powerful than the content your users are submitting really needs. Something much simpler, like Markdown or a WYSIWYG editor may be all you need.

Template engines have very bad performance costs
Somewhat True. Most template engines are doing nothing more than string manipulation, quite often through the use of regular expressions. String manipulation is computationally intensive and if implemented poorly extremely so. A good template engine will only incur this cost once when the template itself is modified, but many incur it every time the page is accessed. Worse yet some template engines require every add-on to manually parse the same blocks of text multiple times. If your site becomes very active then this penalty is going to add up rather quickly and your users will find another site to visit when the pages start taking more than a couple of seconds to load due to demand.

The Take Away
The real benefit of a template engine is the separation of application from display logic. The core take-away, though, is if you understand that then you can do the exact same thing without yet another template engine. A poorly documented template engine will drive your designers and programmers insane, and have a hefty learning curve. The more complex, and capable, your template engine is the more likely it will be the programmers who have to work with it anyway. If you limit the scope of the language that the designer needs to learn then it can be almost as easy on them as trying to teach them the template engine's syntax. It will also be one less subsystem to maintain.

Current Mood: contemplative contemplative

2 comments or Leave a comment
Asa Ayers From: Asa Ayers Date: December 30th, 2012 05:23 pm (UTC) (Link)
While your points are valid and accurate I think it's important to remember that there are different types of developers. There are those like us who spend free time learning learning and thinking about programming. Then there are the developers who do it because it's a job. "if you understand that then you can do the exact same thing without yet another template engine." If you're working with others who aren't on your level, it can be much more efficient and peaceful to simply choose a templating engine like Twig that enforces good behavior.

I also like the more consistent syntax you get out of using a templating engine. Indentation is always a mess mixing PHP with HTML, which I've seen people half-solve using echos with heredocs, but then it breaks the IDE's ability to recognize HTML tags.
zimzat From: zimzat Date: December 31st, 2012 11:17 pm (UTC) (Link)
If I understand correctly, you're saying that the task should be simplified to account for inexperienced developers, rather than educate the developers to do their job. Is that correct? That seems like a good way to smooth things over initially, but then the team will never be very efficient, it hobbles everyone else, and that person will never learn to be better. That's like telling a new developer that using functions is okay since that's all they know how to do, and that they'll never be asked to develop in objects even though the application was written using OOP.

I never endorse putting HTML in PHP strings. It's a disaster waiting to happen, and as you put it the IDE has trouble (if at all able to) highlight the HTML syntax.

I think we might be talking about slightly usages of PHP for templates. When I say use PHP for templates I'm thinking of the way that Zend Framework 1 does it. See the first example on this page of a PHP template. It has loops, variables, checks, etc in all the same places that a template engine would, It's slightly more verbose, but it's also going to be more efficient and flexible for those cases where I need to do something more advanced. Best of all the indention is correct and the PHP's interference with the HTML is minimal.

I should clarify that this post was generated by aggravation with the template engine in ExpressionEngine (and a discussion on a Google+ community). It uses vaguely similar syntax to numerous other template engines, but the exact usage is slightly off, vaguely documented, and lacks any sort of advanced functionality. On top of that internally every single plugin has to re-parse a string block of text for its own variables to regular expression or string replace, over and over.
2 comments or Leave a comment