Walrus.js - Mustache on steroids
documentup.com
documentup.com
[1] I am the creator of mustache.java
The power of Mustache (and Handlebars) was that it forced you to write logic-less templates. There's just no way to express logic other than checks for existence of values. That means that you have a minimal language that every non-programmer [1] can understand. You can change templates without diving into a language. Walrus changes that to be a pretty much full featured template language with full view logic (hey, look, there's MATH methods in there). It perverts the idea of Mustache.
[1] aka designer or template-guru :)
How come? If your base HTML templates are say python or ruby templates they could be localized fine. And if the JSON content your parsing with Walrus comes from the same backend and is also localized where's the issue?
It's mustache with some view logic sugar which makes a lot of sense as far as i'm concerned and would allow your HTML templates to be mostly 'logic free'.
Contributions always welcome :)
Plus there's the whole thing that ‘logic-less’ is a big white elephant: templates need logic, or they quickly become unmanageably bloated and un-DRY. Being able to iterate and conditionally branch are fundamentals essential to templating languages, and so whilst Mustache is an interesting starting point, it's usually not the best solution.
Of course, the one benefit Mustache does have is parsers in lots of languages, allowing you to share templates across client and server-side — it'd be great if somebody were to invest time in producing (say) a Ruby version of Walrus, as it looks like a very useful tool from reading through the docs.
Logic-less templates are a red herring and I cringe every time I enter a project where someone has drunken the Kool-Aid.
There's the rare fringe use-case where logic-less templates make sense, e.g. when you need to accept templates from untrusted sources (user editable) or when you really can re-use them across tiers to a significant degree.
In pretty much all projects neither is the case.
Instead, they quickly turn into a ball on a chain that constantly gets in the way and causes more problems than it solves.
This is my experience from encountering them in nearly a dozen projects and from having fallen for the temptation more than once myself.
Maybe I'm misunderstanding this, but you can do some fancy stuff with handlebars.js. You can 'foreach' through a json collection right in the template, 'if' 'else' statements and a whole whack of other cool little logic statements. So far I've not found anything I can't do in handlebars that I could do generating the page server side. Maybe I'm missing some more advanced cases or misunderstanding the term 'logic-less'?
As for bloated template code? I really don't know what you are talking about. Perhaps you just haven't seen well written mustache templates. My startup, Bagcheck, and Twitter (where I now work) have switched completely to Mustache. It really does work well if you use it properly.
I don't think that adding logic, filters, etc explicitly to the templates is the right answer. Such things tend to accelerate and encourage big ball of mud apps (in my experience ymmv). It also makes it harder to have a consistent cross-platform experience. I really think a better solution might be to have a simple callback mechanism. So for instance, a tag:
{{*foo}}
Would result in the renderer looking in the context dictionary for a key "foo". If the value for that key is callable, it calls the function (with the context dictionary as an argument), and replaces the tag with the return string of the function.That's it. This can mitigate many of the pain points of the templates, while still making consistent implementations across languages easy.
It is still a bit tricky in the "templates are the same on client and server" case, because then you need to implement a function twice (potentially), but I think I would rather do that than descend into some of the templates with logic horrors I've seen (and written myself sadly).
I'm currently using jQuery Templates (which is obviously sub-optimal) just because I would like some basic logic in my templates. This looks exactly like what I need.
It's far easier to make a cut at "no logic apart from boolean checks" and then use a proper client-side framework such as backbone if you need full view logic on the client. It separates concerns and makes clear where logic is supposed to reside. I love separation of concerns!
That works if you are fine with offsetting all (or most) of your presentation logic to client side. But not every web application is the glorified single-page web app, or has significant amount of on-page interaction that would warrant employing a full stack MVC framework on the client side.
> Templates should be about how things look like.
But also what elements are those things built from. Despite attempts at logic-less templates, the presentation layer still must contain some logic and I see no reason to not apply normal coding principles - most notably DRY - to that logic. That's why I consider it very important for a templating engine to allow for reusing things, and splitting things into parts. Here's where some engines really shine (Jinja immediately comes to mind, followed by Underscore or jQuery templates) and others... not so much.
I fully agree with you that having some logic in a template language has its appeal. At first glance it sounds like a good idea (oh, I don't have to go back to the code to calculate that value, nice!) However, as I said, it's a slippery slope and depending on where you and your project end up, you may pay a dire price for that. In the end, inevitable, some part of your logic ends up in the template. (Been there, done that, been burnt)
Mustache/Handlebars allows for most of what you want - reuse things, split things into parts (templates can include other template) without including logic and thus creates a barrier that you cannot cross. It forces you to adhere to best practices.
Mustache is too limited for my taste and seems to force me to pre-render parts of the HTML, so that the template doesn't actually contain all of it. Or there will be many small templates, being combined by some logic that's not clearly visible when looking at the template code.
Handlebars has just enough flexibility to allow me to put all HTML in a single template, using {{#if}} and {{#each}} to navigate the data. Then I can add helpers and new data model properties to add formatting and logic.
The sweet spot of logic for me means that I only use a single identifier in the {{#if}}, such as {{#if adminAccess}}, and make "adminAccess" a property of the data model. So then whoever reads the template is not trying to parse huge logical expressions in the if clauses, but only sees their results assigned to identifiers.
(Earlier, Mustache was even more limited, because it didn't have the concept of "this" ({{.}}) when iterating arrays. As I understand, this has later been fixed.)
Regardless, I wouldn't even consider Walrus until there was server-side support.