3 ms·

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 probab

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

sunkencity 15y ago
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.
jkmcf 15y ago
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 http://slim-lang.com). It's pretty much html w/o the closing tags and brackets, and also like haml but cleaner looking.

sunkencity 15y ago

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.

jkmcf 15y ago

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 http://slim-lang.com). It's pretty much html w/o the closing tags and brackets, and also like haml but cleaner looking.