PHP should not be your template engine

(The estimated reading time for this post is 3 minutes)

PHP is probably the language that most people trying to do something dynamic in the web start with. It”s easy to learn (and hard to master) and you get results really quick which is a lot more motivating than having to write many lines of boilerplate code that looks like black magic.

PHP suffers from many design flaws that can”t be easily repaired without turning it into something non-PHP but that is a completely different story that I”m not talking about here. You can be productive in PHP and if you know what you are doing you can write good software that scales well and that many people can continue developing (which is a huge benefit that some people sometimes forget).

When you are writing a non-trivial software that generates HTML you”ll need some kind of templating (If you don”t do templating you are doing it wrong. Seriously. This is not just some opinion, that”s just how it is.) to separate logic from what is really sent to the browser. Your “real” program does the calculations, the database queries and data transformations which are then given to the template that “knows” how the HTML is supposed to look.

The advantages are obvious: You can change the look of a page without changing the actual code which allows you to work better in teams. Your designer who can”t really code can still work with the data you”ve given him and that you have set up properly. No need to worry about breaking code while trying to add an image. It also makes your business logic, the code that actually does something, simpler, leaner, easier to understand and all in all better. It”s just easier to fix a bug when your code is not cluttered with “&lt;a href=\”” stuff in it.

Now especially in the PHP land you sometimes get people that claim that PHP does not need a templating system because PHP is just a big templating engine. Since PHP is build to mix PHP code and HTML you find basically HTML files with some processing sections in the top of the file and some variables and loops thrown in the HTML code. It might sound smart since you get rid of an abstraction layer which might make stuff faster but is that little overhead really worth it?

The point of a templating engine is that it”s just doing formatting, no calculations or database queries (which is all stuff that the business logic has already taken care of). This is the reason that many templating engines just offer a small subset of the features that “real” programming languages: The templates don”t need all those features and actually shouldn”t have them.

The fact that templating languages are that reduced help you with the separation of layers of your application: If you come to a point where your template is not really able to do what you wanna do with the data you probably have stumbled on a point where the business logic should do more heavy lifting (or where your programmer writes a filter to extend the templating system with a specialized function). Having an “all powerful” templating engine introduces the opportunity to break more things, it is harder to learn for designers who are not programmers and it can lead to you not separating your layers properly.

Of course you can still violate the layering even with templating engines, but the danger is smaller and everything that makes your code easier to understand makes the web a possibly safer and therefore better place.

PHP is just in danger because the language itself is build upon mixing code and HTML but it”s true for other languages, too. If you put “&lt;img src” into one of your django views you are doing it wrong. The limitations of templating engines are a blessing in disguise, your results are better exactly because of the limitations they enforce.

Written by: