Tapestry

Tapestry is very similar to JSF.

However, it uses Convention-Over-Configuration to greatly reduce configuration and simplify UI development.

Just like JSF Facelets, Tapestry has its own templating engine. Tapestry template files end in the .tml extension.

The most significant convention is that every page Foo.tml must have a corresponding Foo.java.

Foo.java is a POJO and is automatically a Tapestry Bean, no configuration is necessary.

Secondly, Foo.java can only be accessed from Foo.tml and not from any other template.

Thirdly, any method in Foo.java can return a class (say Bar.class), or a string (say "Bar"). This tells Tapestry that the next page to display is Bar.tml

These simple conventions go a long way in making a Tapestry project very organized.

For example, in JSF, since any page can refer to any Bean, very soon it leads to a criss-cross of references from pages to Beans. If a page is deprecated, it is not clear if any of the Beans need to be deprecated as well. In the absence of convention, pages and Beans become disconnected (eventually, a mess).

Tapestry, because if its one-to-one relation between pages and Beans, makes it very clear how pages can access Beans. If a page is deprecated, the corresponding Bean gets deprecated as well.

This is one example of how Tapestry conventions make things simpler. There are several others.

Another example, since a Bean is associated with exactly one page,  maintaining state is non-ambiguous. In JSF, if a Bean is called from several pages, some of its state may be set by one Page, other by another Page - leading to a chaotic situation.

Finally, building Tapestry components is way easier than building corresponding JSF components.

There are many other optimizations and scalability that Tapestry is able to deliver because of its well thought-out conventions.