对于Play Framework 1.x，日本的Rythm模板引擎优势？

Question

Rythm is a template engine for Play ! framework views.

It is type safe and provides an alternative to default groovy templates.

Japid is also a similar template engine for Play ! Both Rythm and Japid are solving similar problems.

Rythm

http://www.playframework.org/modules/rythm

http://www.rythmengine.com/

Japid

http://www.playframework.org/modules/japid

What are the advantages of Rythm over Japid ?

Answer 1

Rythm syntax is close to Play2 template syntax so the migration path will be easier.

Razor syntax on which is based Ryhtm was defined for C# templates and is clear and consistant.

In the other hand, Japid is older than Rythm and so can have more features and less bugs

Answer 2

The biggest advantage of Japid over Rythm is the former has an Eclipse plugin while the latter has no tool support at the moment.

Rythm wins at providing better Play-1.x integration. See Integration Guide and Migration Guide

Another thing worth mentioned here is Rythm by default escape expression output like Groovy engine while Japid require you to explicitly escape it as ${escape(expr)} . That says Rythm tends to be safer to use while Japid votes more on performance.

There should be no other big differences in terms of feature set of the both from my understanding. - Green, Author of Rythm

Updates

Rythm has just released a feature called String Interpolation Mode (SIM), which allows you to omit argument declaration for simple cases, make it a good replacement for String.format in most cases:

String result = Rythm.render("Hello @who!", "world");

Note SIM beats String.format in 2 ways:

1. Performance. Rythm.render is 2 to 3 times faster than String.formant
2. Clear. "Hello @who" is way clearer than "Hello %s".
3. You can pass parameter to String.format() by position only, while Rythm.render supports both passing by position and by name

Answer 3

I've implemented static-mustache library to provide a type-safe template engine based on mustache syntax.

It checks both syntax errors and type-errors (like missing property) at compile-time like Rythm or Japid.

It requires almost zero build configuration (in contrast to both Rytm and Japod which require custom plugins) as it's a standard annotation processor.

In static-mustache all type-information is extracted from a normal Java-class used for rendering. A templating language remains pure "logicless" mustache. So templates can be shared between server-side and client-side renderers.