Engineering the HiFi CMS: On Templating
It's no secret that we're working on a new service: HiFi, a content management system for designers who demand nothing less than a high-fidelity translation from a PSD design to live website. The space between PSD and HTML is filled by a templating language harmonizing a website's content with its beautiful, semantic markup.
If you've worked with a content management system before you've probably hated or tolerated its templating language. So have we.
Our internal CMS employs the use of Smarty, a popular and generic templating language for PHP. We tolerate it. The last major release of Smarty was nearly six years ago back in 2003. Since deciding to build HiFi our driving question has been "what should a great CMS look like for the 2010s", not the 2000s.
What's wrong with yesterday's templating languages?
A lot. We're in the process of surveying the good, the bad, and the ugly, and doing some prototyping of our own. Some of the most fundamental problems are already clear, though. Let's take a look.
It's Not a Language, It's Advanced Search/Replace
Many of today's templating "languages" simply search for template tags and replace them with instructions. This can take you a long ways, and the initial implementation is simple, but it leads to poor design decisions by constraining language possibilities to the tasks regular expressions solve.
Moving to a full-blown language processor (lexer/parser/compiler) removes most of the unnecessary constraints and code base scaling nightmares faced when everything is a regular expression search/replace. We're using techniques and best practices straight out of compiler textbooks to make sure HiFi's templating system is as simple and powerful as possible.
Most Errors Surface at Runtime
In most of today's templating languages the only way to find errors in your template is to run the template. So front-end developers get into a cycle of coding, running, hitting an error, coding, running, hitting an error, etc. Lots of these errors are simple ones, like the misspelling of a variable you're printing.
One of the benefits of moving to a full-blown language processor is the ability to do more analysis of a template's content. We can improve the experience for designers writing templates by issuing meaningful errors earlier. We can look at your template and, without running it, tell you "hey, this variable 'daate' you want to print in this if block that only runs on Mondays will never exist".
We believe improving the diagnostics of template coding will make writing template code much more enjoyable.
Weak use of Expressions
Arithmetic in view code should generally be avoided but scenarios exist where it or other expressions are the best way to carry out the task at hand. Assigning a new variable a calculated value, doing date arithmetic, using conditionals, etc, are possible throughout. We're aiming to make expressions natural and consistent.
What are your templating language loves & woes?
Is there a particular templating system you absolutely love or absolutely hate? Features you can't live without? Let us know in the comments as we're hoping to find great influences for HiFi. Also, be sure to the HiFi mailing list as we roll out announcements and a beta program in upcoming months.