I've seen lots of template systems in Ruby, but haven't been really been happy with any of them. Over the last few months or so I've kept notes of the ones I looked at. This is the list I came up with, and some comments on each. But first a disclaimer:
I have NOT spent a lot of time looking at these - there are far too many for me to have time to go into a lot of detail for each of them. Some I know well, many I only know from a cursory review, so don't write an engine off just based on my comments. Also, I very much welcome corrections (or additions) in the comments
Wildcards
These don't fit in any of the other groups below.
-
Radius.
Pro: Radius lets you define your own "tags" - the input is "almost XML" (it uses namespace prefixes, but relies on the prefix value, not the namespaceURI it's tied to - I don't know if that's intentional or lack of understanding of XML), which should let a lot of editors work well with it, and possibly (if you're careful) roundtrip it into web dev tools. It's also designed to be able to output any text, so it's not tied to HTML
Con: It's not actually a templating language, but a tool for creating your own template systems (that certainly makes it more flexible, though).
-
HAML.
Pro: Very compact syntax.
Con: Whitespace matters. I ignore Python because of that (even though, as any Pythonista will tell you it's not nearly as bad as people say it is, which is probably true) - HAML would have to be a hell of a lot more compelling to overcome my innate dislike for that. It also just doesn't "feel right" to me. I'm a syntax snob, and not afraid to admit it: Either I like it or I don't. If I don't like the syntax I won't touch the language with a ten meter pole no matter what.
-
cs/Template.
Pro: Fast (written in C). Uses paths into a tree of objects (like TAL/Amrita style engines). Not tied to HTML/XML. Almost safe to for external content (you'd need to disable "eval")
Con: Not pure Ruby. Looks like you'd need to dip down into using the eval mechanism fairly frequently as control structures supported directly look fairly limited. Doesn't seem to allow user extension of the "macro"'s provided without dipping into the code, which would negate this point
eRuby style
Ruby code and text intervowen.
-
ERB
Pro: Part of the Ruby standard library, and so it adds no external dependencies.
Con: Templates are not much more than a string with Ruby interpolated. The Ruby is sprinkled in as "tags", but those tags are not valid XML tags, so editors that have strict XML modes will treat the tags as content (whether that's a good or a bad thing is purely subjective, I think - I don't like it). If you're using ERB, what's the benefit over just using standard Ruby interpolation syntax ( #{ ruby code here } )? Not much, as far as I can tell, other than some basic convenience functionality, and some very limited safety features.
-
eRuby
Pro: Faster than ERB
Con: External dependency. C extension
-
Erubis
Pro: Faster than ERB / eRuby. Automatic escaping of variables possible
Con: Same as for ERB
-
Galena
Pro: Embed templates directly in your Ruby classes. If you for whatever reason don't want to split your views out from your code, Galena at least lets you format the text in a somewhat cleaner way than lots of variable interpolation.
Con: Tight coupling of code and data. Even tighter than with "cleanly" written ERb if there is such a thing...
-
Tenjin
Pro: Exists for multiple languages (Python, PHP, Perl, Javascript(!), Ruby, Java) with mostly the same syntax. Lots of features
Con: Embedded code as the other ERb style languages, and this largely negates having it in multiple languages.
Liquid style
Text and "code" in a template language that is generally designed to be "safe" to varying degrees, up to and including allowing users to submit templated data without enabling execution of arbitrary code.
-
Liquid Markup.
Pro: Aims to be safe, by preventing people editing the templates from running arbitrary code on your servers.
Con: Another "language" to learn, though simple. Syntax for attributes etc. deviates from conventions shared by many other Ruby template languages.
-
Ruty
Pro: Seems to be safe, by preventing arbitrary code or infinite loops. Very flexible set of filters. Template "inheritance". Mechanism to allow passing arbitrary "context" objects in without exposing unsafe methods to the temples.
Con: Same as for Liquid
-
PageTemplate
Pro: Seems to be safe. Looks like a sort of mix between a Liquid style template language and Textile style (apparently inspired by Perl's HTML:::Template, which I haven't used/looked at)
Con: Not sure - personally the syntax didn't do it for me.
Amrita/TAL style
These look like pure XML (though many TAL-like template systems for Ruby and other languages violate XML expectations they are often close enough to be manipulated with a non-validating XML parser).
- Amrita
Pro: No code in the templates. Uses id's on the tags to tie the template to the model data. Can be "compiled" to Ruby like TAL
Con: Uses REXML (slow) for XML parsing. Very basic functionality unless you provide Proc objects as part of the model data - like Radius it probably needs an extra layer to provide more advanced functionality for use in typical applications if you want to retain a clean model/view separation.
- Amrita2
Pro: "Compiles" to Ruby like PHPTal does rather than parsing templates each time. Much more flexible than the original Amrita. "Filters" can be applied to values to be output to handle rendering/formatting of values etc.
Con: Complex (including supporting a really freaky syntax called AMXML as an alternative to the more TAL-like syntax). Seems to loose the relative safety of TAL-type templates by having several mechanisms for embedding Ruby. Too many ways of doing things.
- Kwartz
Pro: Exists in both a Ruby and PHP version using the same syntax for the templates, it seems. Appears to be very flexible. Should roundtrip easily to HTML editors. No logic at all in the templates
Con: "Compiles" to ERb. No logic at all in the templates (yeah, I know, this can be a good thing too - depending on your use-case - the Kwartz approach is a bit extreme, though it seems). The logic/code uses a second template syntax instead of being just a file of valid code.
Markaby style
These tend to look like Ruby block notation, and make markup look purely like code.
-
Markaby.
Pro: Markup as Ruby. Very simple and follows Ruby DSL conventions
Con: Markup as Ruby... Inside a Markaby template "self" is the Markaby builder.
-
Maline.
Pro: Simple to read; Follows fairly standard Ruby DSL conventions.
Con: Does it actually offer anything "new" compared to Markaby and others that use almost exactly the same block syntax? I can't see any differentiating factors (I haven't looked very hard, though), but the author is clearly aware of Markaby (it's mentioned on the site), so I'm sure he has his reasons.
-
Builder::XmlMarkup
Pro: Very small and simple. Comes bundled with Rails if that's what you're using.
Con: Limited to XML generation (but that can of course also be a plus if it's just what you need)
(Note: This originally said Builder was tied to Rails - corrected based on a comment below)
Wiki / Markdown / Textile style
These are "plaintext" or wiki style markup engines that aim to turn reasonably natural text into HTML or other output and may not have much in terms of variable expansion etc. as that's not their purpose. They will typically be unsuitable as a view templating system, but are useful as 'part of the arsenal' to handle markup of user generated content in a safe way.
- RedCloth
Pro: Textile for Ruby - "Plaintext like" / wiki type markup. Great for comments interfaces etc. to get mostly natural input without having to make people write HTML.
Con: Not a full featured template language (which is ok - it's focus is on turning text into HTML). Syntax seems slightly out of tune with how I'd write plain text, and so it's still yet another markup to learn.
- BlueCloth
Pro: Markdown for Ruby - Platext / wiki type markup. Very similar to Textile / RedCloth in target, but to me Markdown syntax feels more natural for some types of text.
Con: Not a full template language (which again isn't it's goal).
Seemingly dead projects (with or without code available)
In addition to the 19 above, I've come across a number of projects that appear to be dead, dormant or just haven't gotten properly started yet. I haven't looked more closely at them, but have included the links here. Descriptions are from their web-pages.
- RSmarty: An implementation of the lightweight Smarty template language in Ruby.
- Tempura: Tempura is a amrita like template library for Ruby to create a live XML document that combine real data into a XML template. Features: model data is an arbitrary ruby object; separate between view and model; support for event-driven web application.
- TAL: TAL is a flexible XML-based templating system designed to reduce development times for XML-based document generators.
- Curtis / Punk: Simple Ruby Template Construct to reference div's and there id's as if they were a Ruby Object. Also allows binding of Arrays and Arbitrary Objects to populate the specified variables.
- Erby: erby [pronounced 'errr-beee!!!'] is a templating library built on top of ERB. You can create templates with a high level DSL, attach behaviour to these templates and then plug them all together nice and fancy!
- RBML: Create easy to read templates for web sites and applications, using familiar ruby syntax.
- RTALS: rtals stands for Ruby Template Attribute Language. It uses an XML markup syntax in the construction of templates.
- Tie: A simple template system in Ruby. It merges parameter file(s) with template file. This is a wrapper of ERB. The template, and parameters can both take Ruby syntax.
- RVelocity: RVelocity is a general-purpose template engine parsing VTL(Velocity Template Language). It's another implementation of Apache Velocity in ruby.
- RailTags: A Ruby on Rails template system based on Radius. Tags are XML-based and prefixed with rails: namespace. To add functionality all a user does is add functions to railtags.rb.