Why is mustache templating so popular?

Hi!

First of all, I’m not only targeting mustache, but all template engines using an embedded whatever language (curly bracktes), this goes for client-side as well for server-side (Smarty, Handelbars, Angular, React, Ractive, Twig, Underscore, EJS, Hogan, etc).

Second, I’m not fishing for a separation of concerns answer.

As I see the current state of the art, you either render your templates front-end or back-end for the entire site, but never consider rendering them on both sides. For instance, how do I render my angular template server-side? It however, seems nobody embraces that. Or how do I render my twig template client-side. There’s a js library in the meantime, which brings me to antother point, because they introduce new languages they will always depend on a certain system.

Then, logic-less, what does that even mean? It doesn’t prevent logic at all. And it’s still spaghetti. We should be writting logic-free templates instead!

I belief replacing {{strings}} with other strings is the wrong approach. We are working with html and eventually with the DOM. Yes i know, everybody dislikes the DOM, but we really should be working with nodes instead, and not with curly brackets expressions.

I am currently actually working on my own template engine that approaches what I mentioned above. You can get a glimpse of the api here.

So, why are those template engines so popular? Why arent we still using engines such as pure.js, plates or MTE anymore? Is it simply a lack of promotion, so everybody is following the big corporations?

Thanks!

I think that it’s mostly due to Mustache being able to do a good enough job without having too many drawbacks. For something to take over in its place, that something else has to either be significantly better for it to have any traction. Until that type of situation occurs though, inertia remains with what people currently know and use.

My impression is that {{string}}-replace solutions are more versatile and more simple.

More versatile because they’re not limited to just HTML. We could create templates for JavaScript, or Markdown, or JSON, or literally any text-based format.

Also more versatile because the HTML templates aren’t limited to only what CSS selectors can identify. We can put placeholders in HTML comments, or in the middle of an attribute, or in the middle of text. For example, By {{ artist }}, or href="/path/{{ id }}".

And more simple because it’s a glorified search-replace. It’s very easy to understand what ends up where.

1 Like

As I see the current state of the art, you either render your templates
front-end or back-end for the entire site, but never consider rendering
them on both sides. For instance, how do I render my angular template
server-side?

Templates processed BEFORE they get to the browser are server-side. Twig/Smarty etc

Anything rendered after it get’s to the Browser is client-side. React.js is actually client side. Why would you do this I have no idea mind as if the client has JS turned off the page won’t render.

I know the difference between client and server side. What i mean by that is that I need to know where I’m going to render my templates. After choosing angular, there is no way I can render them serverside (with php for instance), nor, if I choose Smarty on the frontside (using javascript). My complaint is, that those systems don’t allow you to choose where you want to render them, they totaly ignore each other. I still want to be able to render my templates serverside, even I’m using angular in the front.

While that’s true, because it’s a very straight forward and simple approach, I belief it still doesn’t fit the needs of html templating. It still depends on expressions and logic.

Angular is a full MVC framework?

And you can I have done it a few times adding it to symfony projects: http://www.daryllaroche.com/blog/?p=136

It goes Twig → Angular Template → Final Html

Very interesting link, thx! But it seems like a mess to me. How about Angular → Twig → html?

No. TWIG as in server-side needs to run BEFORE client-side JAVASCRIPT. You can’t pass Javscript in the browser and then handle the PHP stuff it doesn’t work that way.

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.