Opinion: On Fluid Templating

When I wrote my first TYPO3 extension in 2010 I couldn't believe how ancient parts of the framework were. Especially the templating seemed ridiculous to me because, as someone who has worked with phpBB2 before, I was used to real loops in the template. I had even written a few simple template engines myself that had a lot more features, were probably faster and took me only a couple of days to implement.

Those were the old days. Now we have the ExtBase framework, and with it comes the Fluid template engine. And now that we have left the hiccups of ExtBase 1.3 behind us the framework is pretty stable at most times. It was clearly a huge improvement for the TYPO3 platform as a whole.

However I didn’t really understand the motivations behind the Fluid syntax right from the beginning. I would imagine that it could have been something like this:

It makes sense to use a syntax for templating that is similar to the syntax of the content in most template files: HTML. And because syntax highlightning (and human brains) will most likely explode if we nest tags and attributes, let’s introduce a second inline syntax.

In my opinion the Fluid syntax brings a few flaws with it that could have been prevented, for example by using HTML comments like in the old times as well as a more specific variable syntax (e. g. {{variable}}).

That is why I tweeted this a few days ago:

which roughly translates to:

Today shows once again why it’s not a good idea to base a template language upon XML. #typo3 #fluid

Why do I think so?

1. Fluid hates JavaScript

First of all JavaScript and the Fluid inline syntax don’t play well together at all. Of course you can wrap your JavaScript code in CDATA blocks but this is only a partial fix. How about inserting a path into a JavaScript object?

<script>  
    <![CDATA[
    var myObject = {};
    ]]>
    myObject.myProperty = "{f:uri.resource(path:'js/lang/',absolute:1)}";
    <![CDATA[
    moreJavaScript();
    ]]>
</script>  

Granted, it can be done, but it’s clearly not elegant.

2. Fluid hates CSS

The same is true for the CSS syntax, however that isn’t much of a problem because inline CSS (as in <style> tags) is very rare. However there is another problem concerning CSS.

Back in the old days we used TemplaVoilà to tie a static template file to our highly dynamic CMS. Apart from the huge and incomprehensible XML structures that worked quite well. It meant that Web Designers could work on static template files while programmers already started filling the blanks with dynamic content.

With Fluid this doesn’t seem to be possible anymore. I spent the last days (once again) searching for a practical solution to that problem – and failed. Which means that there has to be a point at which the programmer starts to cut the design into pieces. In the best case those pieces will only be <f:section> tags, but in the worst it will be separate files (partials).

Why do I say best case? Because with sections you can still kind of view the static template file in a modern browser. The Fluid tags will be ignored, but the template will be displayed just fine. Until CSS or JavaScript kicks in and assumes a certain DOM structure:

<style>  
    #header > .menu {
        background-color: red;
    }
</style>

<header id="header">  
    <f:section name="menu">
        <ul class="menu">
            <!-- ... -->
        </ul>
    </f:section>
</header>  

Unfortunately it seems like we have to say goodbye to the good old TemplaVoilà times where we always had static template files for the designer to work on. And to be clear: I know that the Fluid approach has a lot of benefits, e. g. throwing out that crappy XML or working with partials to add the header part of the design to all of my ten template files without duplication.

However it would be nice if it could at least be possible to use the former method, and it would be if Fluid would use a different syntax.

3. Fluid targets developers

From my experience I would say that Fluid templates can become pretty complicated pretty quickly. In fact they can be so complicated that the average Web Designer doesn’t understand what’s happening. So why do we suggest that they have to understand it by using the tag syntax Web Designers are familiar with? Either make the language much simpler or use a different syntax so that they don’t have to care about it.

As a programmer I really hope that more designers – especially female designers – start experimenting with new things like Fluid templates, and I won’t stop encouraging them to do so. However I realize that most of them probably won’t do it. Not because they are lazy but simply because of all those other changes that happen in frontend development right now, like preprocessors, build tools and new possibilities in HTML5 and CSS3.