The reason there are so many template languages is because there are so many use cases. Oddly enough, I'm beginning to think that plain old functions are probably the best solution... assuming you have a nicely nestable syntax, like a Lisp or something whitespace sensitive, like CoffeeScript.<p>ERB and <%= friends %> are great if you have some blob of text and need to sub in some variables.<p>Markdown is great if you've got a prose document, that want rendered nicely.<p>You can combine to form erb.md if you need a document with a dynamically filled in field or two.<p>If you're writing a lot of HTML, then I happen to quite like HAML, since it's a lot less verbose.<p>However, once you start writing ERB or HAML, or whatever, you're greatly reducing the involvement that designers can have in the process. If you're working on a traditional web site, that's potentially a bad thing. However, if you're making a richer web app, it might actually be a good thing to preclude non-programmers from interfering.<p>But let's say you have a more traditional web site & have designers on staff who you want to be able to tweak and preview in their browsers. Well, for one thing, it's a lot of work to keep that working. Since even the presence of a single master layout will necessitate some sort of tool to host the rendered page for you... so I'm not sure I understand the benefits of Mustache's HTML-compatibility in that case.<p>Regarding "power" and "expressiveness" in templates: If you have immutable objects (or at least treat them as such) and you pass data structures, sans methods (such as in a functional language), then you really can't do much harm with those objects alone. It's once you `require 'models'` from your templates, be it explicitly, or implicitly via `template_arg.do_some_query` that bad things start to happen in terms of separation of concerns.<p>For me, I want to do things like validate that every single `input` element has a valid `id` tag. The fact that I have one syntax for partials and one syntax for elements and another syntax for form fields is confusing to me. Why don't I just make an `element` function and then define an `input` function and then `textbox` function and then a `layout` function and then a `button` function? Consistency and simplicity is beautiful.<p>Unless I write `require bigscarylibrary` at the top, or pass an unholy (ie. all) ORM object to my views, what could go wrong?<p>....wow.... I think I'm turning into a curmudgeonly lisper....
Coming from Python/Django, I forgot that the Rails crowd does not have a templating language (as part of the framework, at least). So I was kinda wondering what "future" was being talked about. Even Java frameworks have many template systems.<p>My quest now is to actually push all the rendering logic to the client. The project I am currently working on is already very heavy on javascript, so there is no way to do "graceful degradation" for browsers without javascript enabled. Ideally, my server should just respond with JSON (or XML), and the client takes the response and renders the HTML.<p>So far, the biggest pain with this is to debug a template. Using the jquery tmpl plugin, you just get a blank screen if your template is wrong.<p>If someone knows of a good js templating language that offers some decent debugging functionality, I'm all ears.
With a bit of discipline, you can use ERB and still maintain separation of concerns. I think everyone <i>knows</i> that the controllers should do most of the work getting stuff out of the models and into a useful form, and the ERB templates should just drop that stuff into the right spots in the HTML, but too often it's just way too convenient to do something substantial (like hit the db, sort a collection, etc.) inside the template.<p>I guess the idea behind Mustache and other similar minimal templating engines is to <i>force</i> the discipline that everyone knows they should have. Personally, I think the claim that designers should be able to write templates with zero programming knowledge is a pipe dream; Mustache still has loops and conditionals (how those don't count as "logic" is beyond me) and you'll almost always have to use them.
Because Mustache is such a clean language, you can also build some pretty cool features on top of it. For example, my implementation includes concurrent evaluation of a template and the ability to take output + template and produce the data provided for testing, mocks, etc. Those kinds of features would be nearly impossible to implement in any template language that allows arbitrary logic:<p><a href="http://www.javarants.com/2011/10/09/new-features-and-extensions-in-mustache-java/" rel="nofollow">http://www.javarants.com/2011/10/09/new-features-and-extensi...</a><p>All that though is overshadowed by how easy it is to understand the templates and collaborate on them with designers, front-end and back-end developers.
FWIW, GWT's UiBinder takes a similar, absolutely-no-logic approach to templates. No iteration even:<p><a href="http://code.google.com/webtoolkit/doc/latest/DevGuideUiBinder.html" rel="nofollow">http://code.google.com/webtoolkit/doc/latest/DevGuideUiBinde...</a><p>Takes awhile to get used to, but it's nice to have all your logic in the controller, once you're used to it.<p>Plus being only-static HTML, ui.xml files are amenable to code-generation, e.g. making interfaces for the views (which ends up similar to your controller view classes). Java, XML, and build-time code generation are terribly un-hip, I know, but personally something I've grown to like (I have an open source framework, gwtmpv.org based around these ideas).<p>As far as most-pure templating language, I think that goes to the appropriately named "pure", which lacks any notion of it's own special characters in the markup:<p><a href="http://beebole.com/pure/" rel="nofollow">http://beebole.com/pure/</a><p>I haven't used it, so am not entirely sure how well it ends up working in a real-world apps/templates, but it initially seems pretty slick.
Limited-on-purpose technologies can be a great teaching aid.<p>But they aren't so great when it comes time to get work done. You shouldn't be fighting the language. The language should enable you to do what you need, cleanly, without getting in your way.
"I thought I loved Mustache a year ago, but over time I’ve learned just how revolutionary separating templates from views is toward maintainability and collaboration."<p>Wow, it makes me wonder what you were doing before?<p>I'm more a fan of <a href="http://www.handlebarsjs.com/" rel="nofollow">http://www.handlebarsjs.com/</a>. It has a few handy features that are missing from Mustache.
I cannot suggest KnockoutJS enough. Just throw the data to the client; your template is basically inside your HTML file. Knockout will take your development to a whole other level. My team is at the point where we're seriously doubting if our application servers will ever output HTML ever again. We use the RESTEasy framework to output XML and JSON.<p>Try KnockoutJS, just for one page, and you'll see how incredibly powerful and time-saving it can be. Your clients have just as much CPU power in their phones as you do in your app servers; let them handle the view rendering. Knockout is beautiful, simple, and extremely elegant.