7 ms·

Walrus.js - Mustache on steroids

43 points by jeremyruppel 14y ago

spullara 14y ago
This is so wrong headed I don't even know where to begin. You couldn't even begin to localize templates like this without rewriting them. Good luck modularizing the code as well. Stick with mustache[1]. There are very good reasons to not use something like walrus.js that you don't understand when you are starting your app that will become very much apparent when you are trying to finish it. [1] I am the creator of mustache.java
- GertG 14y ago
  I appreciate that you can't go far into technical details in an HN comment, but after a statement like that, you could at least give a pointer to those "good reasons". They might not be as obvious to everyone as you assume.
  - Xylakant 14y ago
    Since I can't peek into the OPs head, I'll have to speculate but here's my take: 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 :)
    - spullara 14y ago
      Thanks, you read my mind.
- tijs 14y ago
  "You couldn't even begin to localize templates like this without rewriting them" 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'.
  - zzzeek 14y ago
    what language/locale does the "time ago in words" (http://documentup.com/jeremyruppel/walrus/#walrus-dates/time_ago_in_words http://documentup.com/jeremyruppel/walrus/#walrus-dates/time...) function return a result in ? Looks pretty hardcoded: https://github.com/jeremyruppel/walrus/blob/master/lib/walrus.dates.coffee#L161 https://github.com/jeremyruppel/walrus/blob/master/lib/walru...
    - jeremyruppel 14y ago
      i18n support has been on the roadmap for some time. Just haven't needed it/had the time for it yet. https://github.com/jeremyruppel/walrus/issues/19 https://github.com/jeremyruppel/walrus/issues/19 Contributions always welcome :)
- kapowaz 14y ago
  Conversely, my experience is that there are very good reasons not to use Mustache (and instead use Handlebars etc.) — there are just too many limitations that force you to push commonly required functionality into an awkward place within the application stack. 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.
  - moe 14y ago
    I agree wholeheartedly. 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.
  - laserDinosaur 14y ago
    "templates need logic, or they quickly become unmanageably bloated and un-DRY" 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'?
    - kapowaz 14y ago
nilliams 14y ago
Interesting stuff. Definitely a fan of these Collections helpers at the very least: http://documentup.com/jeremyruppel/walrus/#walrus-collections http://documentup.com/jeremyruppel/walrus/#walrus-collection...
- Axsuul 14y ago
  I wish handlebars had this. I have to usually resort to having a property tell me if it's the last item in the collection =/ Regardless, I wouldn't even consider Walrus until there was server-side support.
  - jeremyruppel 14y ago
    Walrus has no dependencies, not even on the DOM. While it was built for client-side use specifically, there should be no reason it couldn't work in a server-side environment. I'd be glad to whip up a sample node app if people needed some proof-of-concept.
joshsharp 14y ago
I don't understand why logic in client-side templates is so anathema. I can branch based on a value in a server-side view, why not client-side? 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.
- Xylakant 14y ago
  Templates should be about how things look like. You'll need some minor capabilities to style things dependent on values, but it's a slippery slope: You start out with branch on "exists", then later see that you need to style every even row in a table. Next project you need to style every third row and decide "oh, I can generalize that". And then you end up with a full math implementation. And wouldn't it be awesome if we could branch depending on the length of a value? You start hacking and the next thing you know when you wake up in the morning is that your template language is Turing complete. Now you have another language to learn. 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!
  - Xion 14y ago
    > 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 (...) 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.
notjustanymike 14y ago
I like this. Clearly not everyone is agreed on the cutoff point for logic in templates so having a solution with more options can only be a good thing.
sophacles 14y ago
I like mustache a lot. Particularly because it just works for every language I use, and a huge number of the languages I might use. But it does have pain points (lots of little templates, weird include behavior, some uneccessary repetition, etc). 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).
SeppoErviala 14y ago
Claims to be Mustache on steroids but misses one of Mustache's most important feature - support for most server side languages.

43 points by jeremyruppel 14y ago

This is so wrong headed I don't even know where to begin. You couldn't even begin to localize templates like this without rewriting them. Good luck modularizing the code as well. Stick with mustache[1]. There are very good reasons to not use something like walrus.js that you don't understand when you are starting your app that will become very much apparent when you are trying to finish it. [1] I am the creator of mustache.java

GertG 14y ago
I appreciate that you can't go far into technical details in an HN comment, but after a statement like that, you could at least give a pointer to those "good reasons". They might not be as obvious to everyone as you assume.
- Xylakant 14y ago
  Since I can't peek into the OPs head, I'll have to speculate but here's my take: 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 :)
  - spullara 14y ago
    Thanks, you read my mind.
tijs 14y ago
"You couldn't even begin to localize templates like this without rewriting them" 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'.
- zzzeek 14y ago
  what language/locale does the "time ago in words" (http://documentup.com/jeremyruppel/walrus/#walrus-dates/time_ago_in_words http://documentup.com/jeremyruppel/walrus/#walrus-dates/time...) function return a result in ? Looks pretty hardcoded: https://github.com/jeremyruppel/walrus/blob/master/lib/walrus.dates.coffee#L161 https://github.com/jeremyruppel/walrus/blob/master/lib/walru...
  - jeremyruppel 14y ago
    i18n support has been on the roadmap for some time. Just haven't needed it/had the time for it yet. https://github.com/jeremyruppel/walrus/issues/19 https://github.com/jeremyruppel/walrus/issues/19 Contributions always welcome :)
kapowaz 14y ago
Conversely, my experience is that there are very good reasons not to use Mustache (and instead use Handlebars etc.) — there are just too many limitations that force you to push commonly required functionality into an awkward place within the application stack. 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.
- moe 14y ago
  I agree wholeheartedly. 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.
- laserDinosaur 14y ago
  "templates need logic, or they quickly become unmanageably bloated and un-DRY" 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'?
  - kapowaz 14y ago

nilliams 14y ago

Interesting stuff. Definitely a fan of these Collections helpers at the very least: http://documentup.com/jeremyruppel/walrus/#walrus-collections http://documentup.com/jeremyruppel/walrus/#walrus-collection...

Axsuul 14y ago
I wish handlebars had this. I have to usually resort to having a property tell me if it's the last item in the collection =/ Regardless, I wouldn't even consider Walrus until there was server-side support.
- jeremyruppel 14y ago
  Walrus has no dependencies, not even on the DOM. While it was built for client-side use specifically, there should be no reason it couldn't work in a server-side environment. I'd be glad to whip up a sample node app if people needed some proof-of-concept.

joshsharp 14y ago

I don't understand why logic in client-side templates is so anathema. I can branch based on a value in a server-side view, why not client-side? 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.

Xylakant 14y ago
Templates should be about how things look like. You'll need some minor capabilities to style things dependent on values, but it's a slippery slope: You start out with branch on "exists", then later see that you need to style every even row in a table. Next project you need to style every third row and decide "oh, I can generalize that". And then you end up with a full math implementation. And wouldn't it be awesome if we could branch depending on the length of a value? You start hacking and the next thing you know when you wake up in the morning is that your template language is Turing complete. Now you have another language to learn. 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!
- Xion 14y ago
  > 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 (...) 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.

notjustanymike 14y ago

I like this. Clearly not everyone is agreed on the cutoff point for logic in templates so having a solution with more options can only be a good thing.

sophacles 14y ago

I like mustache a lot. Particularly because it just works for every language I use, and a huge number of the languages I might use. But it does have pain points (lots of little templates, weird include behavior, some uneccessary repetition, etc). 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).

SeppoErviala 14y ago

Claims to be Mustache on steroids but misses one of Mustache's most important feature - support for most server side languages.