HybridJava vs. Tapestry

There are many similarities between Tapestry and HybridJava. Both follow the "convention over configuration" philosophy, opposing the XML madness. Both are Pure Java.

Both Tapestry and HybridJava are clearly component-oriented frameworks. Both frameworks define a “component” as an entity responsible for a region (regions) of the overall page View, for UI events in that region (C), and optionally for some component-local state (M). But here is the difference:

Tapestry: "Components may or may not have a template." In any case each component has a Java class instance.

HybridJava: some components may have no class instance, only a template (widget). We may call such components “lightweight”, though in HybridJava terms they are “just widgets”, not components.

The consequence of this difference in definitions is quite dramatic. In HybridJava a page may contain any number of reusable widgets (buttons, text areas, “if” and “loop” tags and so on) and still be presented as ONE object in memory. Same page in
Tapestry will consist of unnecessarily large number of objects.

Here is the Hello World example from Tapestry site (an object):
  public class HelloWorld { @BeginRender
    void renderMessage(MarkupWriter writer) {
    writer.write("Bonjour from HelloWorld component."); }}

Compare to Hello World in HybridJava (no object created):
<widget name="HybridJava"> Hello World! </widget>

In addition, Tapestry is rescanning templates and building DOM of the page before each rendering, which adds even more overhead. (HybridJava builds DOM once and at compile time.) Tapestry also supports context stack and some queues, which HybridJava does without. All in all it’s hard to expect Tapestry to be fast in production.

There are several nice features of Tapestry that would be nice to have in HybridJava:
  1. Live class reloading
  2. Test readiness
  3. Integration with Hibernate
  4. Third-party integrations with other tools.

Tapestry service builder for common design patterns is a great idea, but we would rather see it as a separate product unrelated to web programming.

We don’t feel that mixins and template inheritance add any value to the technology. Using Injection of Control in Tapestry presentation layer does not look justified either. It does not help the learning curve.

Tapestry overuses annotations. In fact it tries to replace traditional calls of methods with calls “by annotation” which for presentation layer is an obvious overkill. HybridJava does not use annotations at all.

It would be nice to have a Tapestry-like implementation of HybridJava language as an interpreter companion to HybridJava compiler to boost development productivity.

Here is an interesting link regarding Tapestry.