At a conference I recently attended, two separate topics related to templates sparked a debate off-stage about Logic vs No-logic View Templates. Folks were very passionate about the side they represented. Those discussions were the high point of the conference, since I learned much more from them than from the sessions that were presented.
While everyone involved in the debates had different opinions about the ideal templating solution, we all agreed that templates should…
- not include business logic
- not include a lot of logic
- be easy to read
- be easy to maintain
In this post I’ll describe what I prefer–rules, best practices, performance considerations, etc. aside. My preferences come from my experience with templates for medium to complex applications.
Full-of-logic, logic-less, and less-logic solutions
Before I go into the details, I would like to make one thing very clear. Although I’m trying to make a case against logic-less templates, that does not mean that I am advocating the other extreme–i.e., a templating language that allows a lot of logic. I find such templating languages, especially those that allow the host programming languages to be used inside the template, to be hard to read, hard to maintain, and simply a bad choice. A JSP template with Java code in it and an Underscore template with JavaScript in it both fall into the category of being a full-of-logic template. JSP and Underscore are not necessarily at fault here; rather, developers often abuse the additional freedom such solutions offer.
What I am advocating is “less-logic” templates in place of “logic-less” templates (thanks, Veena Basavaraj (@vybs), for the term “less-logic templates”!).
Good and great templating languages
A good templating language should offer, at a minimum, the following features:
- Clean and easy-to-read syntax (including the freedom to use whitespace that will not show up in output)
- Structural logic like conditionals, iterations/loops, recursions, etc.
- Text/Token replacement
- Includes
A great templating language should also offer the following features:
- Ability to be rendered on the server and the client
- Easy learning curve with as few new concepts as possible
- Simple template inheritance
- Easy debugging
- Great error reporting (line numbers, friendly messages, etc.)
- Extensibility and customizability
- Localization support
- Resource URL management for images, scripts, and CSS
The case against logic-less templates
I consider a logic-less template to be too rigid and hard to work with due to the restrictions it imposes. More specifically, here are the reasons I am not a big fan of logic-less templates:
- Writing a logic-less template requires a bloated view model with comprehensive getters for the raw data. As a result, a messy and difficult-to-maintain view model usually accompanies logic-less templates.
- Every new variation to the view requires updating both the view model and the template. This holds true even for simple variations.
- Getting the data ready for the template requires too much data “massaging.”
- Offsetting the rules of a logic-less template requires a lot of helper methods.
Regarding the argument of better performance with logic-less templates: While they might have a simpler implementation, they require additional preprocessing/massaging of the data. You therefore have to pay a price before the data gets to the template renderer. Granted, a templating language that allows more logic might have a more complex implementation; however, if the compiler is implemented correctly, then it can still produce very efficient compiled code. For these reasons, I would argue that a solution involving templates with more logic will often outperform a similar solution based on logic-less templates.
Conclusion
No doubt, there are advantages like simplicity and readability associated with logic-less templates such as Mustache. And arguably, there could be some performance gains. However, in practice I do not think these tradeoffs are enough to justify logic-less templates.
Logic in a template isn’t really a bad thing, as long as it doesn’t compromise the template’s readability and maintainability.
And as an aside, I’m definitely in favor of more debates than sessions in future conferences, since we actually learn more by hearing multiple viewpoints.
I welcome your thoughts!
Credits: Many thanks to my colleague Patrick Steele-Idem (@psteeleidem) for helping me write this post. He is working on some cool solutions like a new templating language; be sure to check them out when they are open-sourced.