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.

Comparison of Web Frameworks

Vladimir Tsvetkov wrote: “It’s interesting weather someone really tried to approach this from more scientific point of view?”
Of course there should be a scientific approach to the comparison of Java Web Frameworks.

... And as any scientific approach that should better end with some numbers. Those from the matrix indeed give little. Giving "the same requirements to 10 teams ..." would be a good idea, if not so expensive. Besides this approach - when each team is "highly-specialized in one particular framework" does not cover the learning curve. Probably taking 100 randomly chosen teams would be better. That is indeed a scientific approach, but out of pure experimental science.

Speaking more seriously we may remember something (alas, mostly forgotten) from early days of science of programming, specifically the things about complexity and the relative levels of programming languages. Things like that are indeed measurable.

Applied to Web Frameworks we may think about some imaginable average Web application with typical functionality as a working entity and then go back in time and estimate the size of same application from the point of view of developer's effort. The developers creatively write what they think about the product developed using certain language, or rather a set of languages defined by technology (aka framework). That includes programming language of course (and you are not going to use Cobol, right?) and other things like configurations, HTML used in various ways and so on. The level of this combined language is high if the given framework permits to code the project with lesser number of operators.

As said experimental parallel programming of test project is not realistic (though the history knows some examples), but same as for comparison languages+compilers some artificial but sophisticated test sets may be developed with time. Programming such a test might take maximum a few days from any team "highly-specialized in one particular framework".

As an example and possibly as a staring point I may suggest a set of tests I have developed to test my own framework - see http://www.hybridjava.com:8080/HJ_Sample/