Mustache, ERB and the future of templating | Hacker News Reader

Mustache, ERB and the future of templating

warpspire.com

63 pointsnfm27 comments

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

Yes, I think too that the right approach is to have a LISP style equality of data and code. I think the reason people use templating for HTML is that it's rather simple do do, it's possible to do the same with PDF but nobody in the right mind would do this. There's a lot of power that comes from using something like clojures hiccup, or seasides html functions, for example the view, can actually contain the view and BE that programmatically, instead of having yet another layer. Templates must die.

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.

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.

New Twitter was entirely rendered client side using Mustache. Some of that mustache is now rendered server side, essentially unchanged.

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.

That was exactly my goal when I first experiment with the concepts [1][2]. As far I as I'm concerned, I think this design strategies is just the next logical step. New javascript frameworks [2] [3] geared toward this paradigm are now getting out of their infancy and are fun to work with.

[1] http://blog.rassemblr.com/2011/05/on-client-side-templating-...

[2] http://blog.rassemblr.com/2011/04/on-client-side-templating/

[3] backbone http://documentcloud.github.com/backbone/

[4] sammy http://sammyjs.org/

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.

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

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.

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

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:

http://code.google.com/webtoolkit/doc/latest/DevGuideUiBinde...

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.

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.

I wrote pure.js to run the frontend of our web app. It is live for about a year now. The next version will be innerHTML free. Thanks for talking about us.

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)

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.

One of the greatest benefits of using my Mustache style ERB approach — there's absolutely no blockers. You can use any crazy ruby you so desire, but at the same time, you can also build clean, documented mustache-style views. I'm hesitant to say it's the best of both worlds, but thus far it actually has been.

Of course, your whole statement hinges on your definition of "cleanly."

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.

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

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.

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.

Does it degrade gracefully?

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.

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

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.

Reply on news.ycombinator.com