

Mustache, ERB and the future of templating - nfm
http://warpspire.com/posts/mustache-style-erb/

======
snprbob86
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.

ERB and <%= friends %> are great if you have some blob of text and need to sub
in some variables.

Markdown is great if you've got a prose document, that want rendered nicely.

You can combine to form erb.md if you need a document with a dynamically
filled in field or two.

If you're writing a lot of HTML, then I happen to quite like HAML, since it's
a lot less verbose.

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.

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.

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.

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.

Unless I write `require bigscarylibrary` at the top, or pass an unholy (ie.
all) ORM object to my views, what could go wrong?

....wow.... I think I'm turning into a curmudgeonly lisper....

~~~
jkmcf
_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._

This is why I'm digging slim (<http://slim-lang.com>). It's pretty much html
w/o the closing tags and brackets, and also like haml but cleaner looking.

------
rglullis
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.

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.

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.

If someone knows of a good js templating language that offers some decent
debugging functionality, I'm all ears.

~~~
tchvil
We have built a web app like you describe, without any HTML coming from the
server. We use pure.js (our lib), 3 things can happen when you debug:

\- the selector is wrong, you get an exception \- the data you want to read is
not in the JSON, eg: an input value is blank \- there is an error in a JS
function, you can debug it like any JS code

pure.js use only CSS selectors, HTML and JS/JSON.

------
baddox
With a bit of discipline, you can use ERB and still maintain separation of
concerns. I think everyone _knows_ 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.

I guess the idea behind Mustache and other similar minimal templating engines
is to _force_ 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.

~~~
kneath
> 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.

This is a bit esoteric, because conditionals and loops are what most
programmers are familiar with. I think the big difference for me is that it's
not really a _conditional_ or a _loop_ but a _context_.

So when I say {{#var}} I'm saying _within this context, output this partial_ —
that partial can be a separate file or an inline HTML snippet. If that context
doesn't exist, it doesn't get rendered (conditional). If that context is a
collection of items, it renders each one (loop).

So, yeah. It's easier to say that they're conditionals and loops since that's
what programmers are familiar with. But if you start thinking a bit different,
you can see how there's really only one mode for Mustache: outputting stuff.
You can't filter the output. You can't output parts of it. You can only output
it or not.

If you spend some time with liquid (a templating language with logic, but with
extremely similar syntax as mustache) you'll notice the difference. It's
subtle, but (I think) important.

~~~
baddox
I see your point, but I think it's really a continuum from templating
languages with a lot of logic (e.g. ERB which gives you all of Ruby) to
templating languages with less logic (e.g. Mustache or some hypothetical uber-
minimal templating language). They're all languages that need to be learned,
and they all "do logic," and I think a sweet spot should be the goal, not
absolute minimalism. I've always been a big fan of Django templates, which are
essentially a subset of Jinja2 templates.

------
spullara
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:

[http://www.javarants.com/2011/10/09/new-features-and-
extensi...](http://www.javarants.com/2011/10/09/new-features-and-extensions-
in-mustache-java/)

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.

------
stephen
FWIW, GWT's UiBinder takes a similar, absolutely-no-logic approach to
templates. No iteration even:

[http://code.google.com/webtoolkit/doc/latest/DevGuideUiBinde...](http://code.google.com/webtoolkit/doc/latest/DevGuideUiBinder.html)

Takes awhile to get used to, but it's nice to have all your logic in the
controller, once you're used to it.

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).

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:

<http://beebole.com/pure/>

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.

~~~
gregwebs
Scala (in the Lift framework at least) and I think a clojure framework both
have a pure like system. I like the approach, and in certain use cases it
should have more advantages. I only used it once, but I think it is easier to
see something in the template than to have to transpose it onto a pure
template in your mind.

------
chrismealy
OK, I'm sold. What's the best way to organize your helpers this way? (90% of
rails is knowing what directory to put things in)

------
wccrawford
Limited-on-purpose technologies can be a great teaching aid.

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.

~~~
wahnfrieden
Sometimes you don't want template designers to be able to accidentally do
something expensive because they didn't know better. Limited templating
languages help to limit this issue.

------
latchkey
"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."

Wow, it makes me wonder what you were doing before?

I'm more a fan of <http://www.handlebarsjs.com/>. It has a few handy features
that are missing from Mustache.

~~~
baddox
Namely, handlebars allows you to use dot syntax to get inside nested hashes
(objects). While you could argue that this isn't a good practice, it certainly
makes it easier to create templates for an existing JSON API endpoint that
contains nested objects.

------
mark242
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.

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.

~~~
Torn
Does it degrade gracefully?

~~~
barkmadley
Of course not. At least not yet. The only missing piece is to bind the data
that is already found in the html to the data found in the view-model object
(or create the view-model object from the html, or some third strategy). This
has been suggested a couple of times on the mailing list, but no-one has
stepped up to the plate to implement it.

------
Breefield
Being able to forget about closing tags in HAML is such a godsend for me, just
saying.

~~~
gregwebs
HAML is good, but abandons HTML too much, which is why we created Hamlet. I
just yesterday released a client-side version:
<https://github.com/gregwebs/hamlet.js>

I did mustache style variable interpolation (but you can stick whatever js you
want in it) because it was easy to implement. I just realized that this style
doesn't allow the insertion of javascript loops, but it would be compatible
with mustache and make for a much better implementation - you also wouldn't
need to close your mustache loop just like you don't need to close your tag.

