Your templating engine sucks and everything you have ever written is spaghetti code (yes, you)

[NorbertH]

Just found an article about templating and it really made me smile:

 Your templating engine sucks and everything you have ever written is spaghetti code (yes, you)

I guess many people here on PW don't give much attention to templating engines as PW runns smooth even whithout one. But the concept of DOM Templating really looked interesting to me. I really would like to hear your opinions!

[LostKobrakai]

I'm not really sold on this. What's bugging me the most about the concept is, that the author suggests using classes and id's to target dom nodes and this obviously has to happen if the designer shouldn't be able to break the app just by moving any markup in the template. Let's say we don't use id's because they are inflexible and maybe the designer needs for example a title to be displayed in multiple parts so id's wouldn't work. To also seperate out the concerns of styling and frontend scripts we would need to do something like this:

<article>
  <h2 class="headline js-collapse php-title">Artikelvorlage</h2>
  <p class="php-text">Lorem ipsum...</p>
</article> 

Of course we would filter out the namespaced classes before rendering, even if the author doesn't talk about this mess of classes...

Now I don't see how this is fundamentally better than this, the mentioned mustache language.

<article>
  <h2 class="headline js-collapse">{{ title }}</h2>
  <p>{{ text }}</p>
</article>

Nobody forces anyone to use logic in template languages. The part that's difficult for each part is the communication between developer and designer about which data are available under which variable name. Nothing can take that of working together on a single product away. 

About the authors rant against designers needing the whole dev enviroment on their machines: Using static html means also static content. The greatest benefit of having the dev enviroment is that you can test your design with dynamic data and not only static content. The designers which are sold with only having static content on their disposal it just a matter of having some default data as json and compiling the html via javascript. 

{
  "title": "Artikelvorlage",
  "text": "Lorem ipsum..."
}

One could even use things like Patternlab, which is there to exactly manage only the designers part of building anything for the web. This does compile all your templates automatically you just need to start a shellscript and you're good to go. That's far from a real dev enviroment.

And by now I didn't talk about multiplying markup (listitems) and things like reusing partial templates.

[NorbertH]

First of all , i got nothing to complain about spagetty code.
Personally i really like to easily mix PHP and HTML in PW Templates, its easy , its simple and its fast.
 
I just took a look at  Patternlab and i personally think its even faster to create some fields and mockup data in PW and then wire it to the Template, than to build a mockup whith Patternlab, Especially when it comes to complex structures where you cant rely on the buildin datasets..(at least not much longer  plus you page is already strapped to a CMS)
 
So if we can live whith Spagetty i guess everything is ok. (Besides from Smarty where they build the whole thing to seperate concerns and then find a system to bring PHP back to the template...)
 
The other thing is about DOM templating ... and there i really whish someone implemented a example TE using dom templating but all Links are down or outdated :-(
 

<article>
  <h2 class="headline js-collapse">Artikelvorlage</h2>
  <p >Lorem ipsum...</p>
</article> 

In DOM, as far as i know you can  address the article tag directly and in addition to that you can even reach all its subelements (article->p). So you basically don't even need any additional classes/IDs at all but maybe for convienience. At least you don't need to spam the whole document whith classes. Often there are already classes/IDs in the template that you can use. And i personally don't think it's such a mess naming  a few key elements.

Looping over elements shouldn't be too hard as you can fetch the container , get its contents, create a new subtemplate modify and append it.(at least in theory) 

One thing worth to mention is that i know many designers that even have trouble to understand  any kind of logic. Thats why things like Bootstrap are so popular, it keeps alll dynamic stuff encapsulated into CSS classes and is therefore functional whitout using a single line of logic. So Templating whith the DOM is at least for the Designer the most simple thing to do , just add some Classes/IDs to things you want to be changed dynamically. But i am not sure how complex it gets when we come to the developers part ;-)

Whish there would be a functional example application, as it would at least be very interesting to see.

At least there seems to be something written in JS :

https://github.com/medikoo/domjs

Btw, i really like Moustache for its simplicity.

[LostKobrakai]

In DOM, as far as i know you can  address the article tag directly and in addition to that you can even reach all its subelements (article->p). So you basically don't even need any additional classes/IDs at all but maybe for convienience. At least you don't need to spam the whole document whith classes. Often there are already classes/IDs in the template that you can use. And i personally don't think it's such a mess naming  a few key elements.

That's true, but I did mention the designer / developer relationship just on the basis of the article. If one is working alone this might work. But just as it's bad for js/css to bind things directly to dom elements it's likewise bad to do that for any php dom templating. Think about what would happen if the article tag would be replaced with a section tag and suddenly the backend code is busted. That's why one would need to use the same conventions, that do apply to scaleable css as well. Both times you want to target a specific dom element. 

One thing worth to mention is that i know many designers that even have trouble to understand  any kind of logic. Thats why things like Bootstrap are so popular, it keeps alll dynamic stuff encapsulated into CSS classes and is therefore functional whitout using a single line of logic. So Templating whith the DOM is at least for the Designer the most simple thing to do , just add some Classes/IDs to things you want to be changed dynamically. But i am not sure how complex it gets when we come to the developers part ;-)

Bootstrap is not dynamic. It's javascript enhanced, but there's not a line dynamic content. If you're concerned that your designer does not grasp if/else statements and recurring blocks of elements (loops) than you'll have a hard time even if you use the dom templating strategy. Also how would they want to get anything done in javascript if they don't get this.

[NorbertH]

Bootstrap is not dynamic. It's javascript enhanced, but there's not a line dynamic content. If you're concerned that your designer does not grasp if/else statements and recurring blocks of elements (loops) than you'll have a hard time even if you use the dom templating strategy. Also how would they want to get anything done in javascript if they don't get this.

If they are ok whith javascript , they won't have any problem whith PHP which makes a TE completely obsolete(most of the time), at least whith PW

Still the main argument is if you walk around telling pepole that your super TE is seperating logic from markup, you better not just replace on type of logic whith another logic, thats just another language interpreted by another interpreted language, that's plain sillyness. And to be true if you want real logic less markup , the only way i know is doing it via DOM or maybe some other kind of parser that does actually the same.(maybe you know something else?)

If you don't care about mixing in some logic, there are many other wonderfull solutions. 

[LostKobrakai]

You're right and I'm really with you, that this is really a replacement of logic. The author of the linked article is right on that part. It's just that using the dom does have it's own issues, if you look at the whole process and not only the designers'. E.g. your designer does implement a popular posts list.

<ul class="list--popular">
  <li>
    <a href="...">My popular post</a>
</ul>

Then the backend guy implements this with some dom selectors.

• .list--popular li > a: Change text to title
• .list--popular li > a: Change href to url
• .list--popular li: Loop for all posts

Now the designer decides that he would like to have a separate link and the title as heading before that.

<ul class="list--popular">
  <li>
    <h2>My popular post</h2>
    <a href="...">Read more</a>
</ul>

This would make the whole dom selection in the backend code obsolete. The link's text would be overwritten and the headline wouldn't get the title it needs. The only way around this by just using the dom would be classes like I proposed above.

Whereas with something like mustache (just ignore the logic parts for a second, just the variable insertion) the designer could have made this change independently from the backend, just move the curly braces with the variable names around. Additionally you could still use all your dom functions to implement things like loops before rendering out the variables. mustache is simply html with some curly braces the dom doesn't care about.

Using the dom could very well be useful in places, but not for basic templating, meaning getting dynamic content in the place the designer wants it to have.

Edit: 

This is really kinda the same discussion as for css specifity. Binding stuff in a scaleable way to the dom is difficult. No matter if it's templating logic or styling. Maybe have a look at this: http://csswizardry.com/2014/10/the-specificity-graph/ and the talk, which includes this as well https://www.youtube.com/watch?v=1OKZOV-iLj4.

[NorbertH]

Finallly i found someone who actually implemented a TE based on DOM templating:

 http://camendesign.com/code/dom_templating

That brings this discussion to the level of having actual examples available

More comes later as i am busy right now.

[NorbertH]

Ok, lets go through this step by step .
 
First of alll i took a look at the two Links you posted:
ITCSS is a really great concept and i guess it will help me organizing my CSS files a lot better in the Future !
 
Second about the Article:
I got the concept why its a bad idea to add IDs, yes its true if you use em they completely break the "flow" of your actual cascade an i already had a load of issues caused by this whith templates that clients simply bought on Templatemonster or so. But the author also stated that he thinks it's ok to use ID's for internal page navigation as those ID have no relevance inside of the CSS, they usually don't have any CSS definitions. So i don't think its doing any harm if you add some more for templating. Its just additional stuff you put into your template same as if you put some TE stuff like {{{something}}}) into it.
 
Third your example: (after some experiments whith the example DOM Template engine)
The change would break nothing but it simply would have the default content in the headline. but this would happen to any other TE too.
For example in Smarty you have to add Variables via  $smarty->assign('variable', 'Value'); . So if you don't assign that variable somehow the content would not be displayed. In addition to that the designer needs an up to date list of all available variables
 
In DOM you would do this by adding one line:
 

$item = $template->repeat (".list--popular");
foreach ($list  as $elemant) {
    $item->setValue ('a', $element->linkname);
    $item->setValue ('a@href', $element->url);
    $item->setValue ('h2', $element->headline); //This line is added to make it display
    $item->next ();
}

In this example i didn't even needed additional classes or IDs. Some of my recent test show that you just need to add a few classes or ids from time to time, plus you can filter em whith a single regex if you choose the names right and its absolutely necessary.

I also see a few advantages in this:
1. You have the full power of PHP available if it comes to decisionmaking, modifying content or anything else.
2. The Template may contain example content, so you can use it independently if you like.
3. You can use static mockup template and simply make it live whithout any changes at all.
So even the Designer can fetch the document whith slightly changed classes and reimport into its editing tool.

I am sure that if you want logic free templates you have to pay a price for this, but i am not so sure if that price is so high like if you are using some of the big bloated TE's of our days.

At least it's a really interesting concept that really deserves a second look!

[LostKobrakai]

Third your example: (after some experiments whith the example DOM Template engine)

The change would break nothing but it simply would have the default content in the headline. but this would happen to any other TE too.

For example in Smarty you have to add Variables via  $smarty->assign('variable', 'Value'); . So if you don't assign that variable somehow the content would not be displayed. 

Your first two statements are not right. The difference in using the dom is that you don't even give the designer the ability to change the place of already implemented content parts (a.k.a. the variables of TE's). To stay with my popular-list example: In both variants the dynamic content is the title and the url of those different posts. Where those are used is, in my eyes, the responsibility of the frontend designer. (I left out the list markup as there's no dynamic content in it.) 

<a href="{{ url }}">{{ title }}</a>

The previous code can be changed to the following without any difficulties or changes in the backend code. 

<h2>{{ title }}</h2>
<a href="{{ url }}">Read more</a>

or even:

<h2>
  <a href="{{ url }}">{{ title }}</a>
</h2>
<a href="{{ url }}">Read more</a>

The same change would have caused your example dom code to break, because for the first case there wasn't even an <h2> and the "Read more" text on the link would be replaced for no matter what link there is. That's why the only "scaleable" way to use the dom alone would be using classes to identify elements, as the type of elements could change in the course of development and id's wouldn't let you reuse content parts. 

I don't want to say it won't work, but I wouldn't want to change the backend dom selectors everytime the markup changes and the classes way of selection is really just some curly braces away from using a templating engine. 

Another great example would be a change in headline hierarchy. Do you really want to change your backend code if the designer decides to put an additional headline above the posts list and therefore the post titles would be inside an <h3> instead of <h2>. That's some spaghetti code in my eyes.

In addition to that the designer needs an up to date list of all available variables

That's true, but at best this is discussed beforehand and not as afterthought, it's still a collaboration on a singular site and not two indepentent projects. To keep the concerns of frontend and backend separated one needs to agree on a fixed baseline, in this case which data are available. 

[NorbertH]

The problem whith changing the elements only occures if you don't use classes or id's as placeholder . If you use em you can far more easily change element.

That's true, but at best this is discussed beforehand and not as afterthought, it's still a collaboration on a singular site and not two indepentent projects. To keep the concerns of frontend and backend separated one needs to agree on a fixed baseline, in this case which data are available. 

So i t looks like most of the problems we discussed here highly depend on workflow and how you collaborate  whith your designers(and maybe their skills).

Btw. we are comparing a higly experimental idea to something thats been stable whith something thats been elegant and stable for some years already(like mustache).

Compared to some of the widespread and completely bloated TE i think even this experimental TE looks elegant, not sure if you agree, but  as you seem to be using mustache i guess you turned your back to those systems too?

[diogo]

I have to say that I like the theory of this

Php dom parsers would have to improve a lot, though... Would be great if you could use a browser dom parsing engine in the server, and work with server side languages on top of that... And I don't mean this only for node.

[LostKobrakai]

I've used mustache solely for my latest project and I've never really used any other templating language. I'm also trying to not be biased about different engines, but to point out my view of how to most efficiently "separate concerns", which is the goal of avoiding spaghetti code. To me this means that the designer should be able to work as independent from backend implementations as possible. Likewise it should be the other way around. If your workflow does not provide predefined datasets you can still go the route of letting the designer use default content from a json file and afterwards the backend guy just needs to couple his output to the variables the designer used.

Edit: If you want to use classes and id's for dom targeting the desinger has to know those beforehand, too. So I still don't really see the benefits of using the dom method, besides that placeholder content doesn't have to be rendered into the html before showing is as static mockup.